Amazon S3 Security (Simple Storage Service)
Infosecurity magazine reported that in December 2020 a Californian telemarketing company had exposed over 114,000 files of data stored on Amazon S3. This data included names, addresses and phone numbers of the company’ clients. Two smaller breaches of UK company data involving personal information were reported by Computer Weekly in January 2020.
Amazon S3 is a cloud storage solution within Amazon Web Services. The segments of S3 storage are called buckets. A bucket is an individual data store but folders can be created to organise files within each bucket. The physical location of buckets are set as they are created. The data protection laws of the user and host county will then need to be adhered to. As of writing (March 2021) free tier access to AWS includes a 5GB storage solution for 12 months (A data limit that a private user could swiftly fill with photo uploads). Charges kick in as storage volume and frequency of access to data increases. With the resources available to Amazon the solution can scale up to very large storage solutions and can be linked to other AWS services. The whole is an attractive business solution; you pay for what you need and can scale up when required.
The solution is relatively easy to sign up to and access. This does not mean that the security options are straightforward. Amazon S3 provide a full security framework with detailed instructions on its use but this is a relatively complex structure and it is the responsibility of the user to enforce security. It is not a ‘one size fits all’ solution but needs to be tailored to access requirements.
S3 buckets are secured by default and an account (blocking public access to all buckets in an account) or individual bucket must be specifically granted public access. The reported data leaks (leaky buckets) are not blamed on a lack of security in the S3 model but that the data owners had changed the default security.
A fully secured data store is of limited business use as that would restrict access to a single data user. Any sharing of information would depend on sharing of a single access account. This exposes full access to data to hackers through phishing or other social engineering attacks. It is also quite unnecessary in a system that is designed with differing levels of access and multiple account options.
Kindus recommends:
• Only set data access to public if absolutely everyone must have access to that data. If some level of public access is required for example to host a static website only the minimum permissions required for a solution to work should be granted.
• Set user policies for access and data. Keep these simple so users can understand them. Set up and use security groups where possible. Permissions from existing buckets can be copied across when new buckets are created. This will pull across good or bad security settings.
• Encrypt data stored on S3. Default server side encryption is built into S3; encrypting all objects in a bucket. The data will be encrypted as it is uploaded then decrypted on downloaded. Alternatively or in addition other encryption protocols could be used on the data before it is uploaded.
• Monitor and log S3 resources and their access. S3 activity is integrated with AWS Cloudtrail. A full transaction log for a bucket can be very large but tracking changes and analysing logs will give a picture of how strong the deployment security is (or is not). Monitoring S3 activity will also highlight where the costs are coming from in a deployment and could enable them to be reduced.
Need some help? Kindus can pen test your cloud hosted data to identify misconfigured cloud storage and provide consultancy during the configuration phase of your project to ensure your system is ‘Secure by Design’.
