I’ve been an occasional user of “the cloud”, a result of working out some data security ideas and threat scenarios in the Amazon EC2 environment. I played at being a system admin while setting up a domain with a few servers, and configuring Active Directory on a controller. My focus was on having a Windows environment that I could do some pen testing. But there’s more to Amazon Web Services (AWS) than EC2 computing environments, and I decided it’s the right time to started exploring more of its services, especially from a security perspective.
There’s No “There” In the Cloud
It’s natural for many in IT (and corporate bloggers with IT backgrounds) to gravitate to EC2. It’s basically a virtual IT facility: Windows operating systems available on different virtual hardware, a virtual network where you don’t have to deal with cables or routers, virtual firewalls, and other network security features.
However, the cloud is more than just a recreation of the IT server room! They call it Amazon Web Services for a reason: Amazon offers computing and storage services removed from their familiar settings.
Need just a cloud file system for sharing and working with documents? There’s Amazon WorkDocs.
What if you just want a Windows desktop environment for your small- or mid-size company without having to deal with all the messy server infrastructure? Amazon WorkSpaces is just for you.
Going a step further, what if you just need enormous amounts of raw storage for web applications, and you don’t really care that it’s not organized as a Windows file system. For that, there’s Amazon S3 buckets.
Need access to an Active Directory environment? Amazon Directory is just the ticket.
In a way the Amazon cloud — and others have similar offerings — is really a collection of separate OS services that are not tied to a specific facility or location: AWS is, of course, accessible everywhere.
AWS IAM , IAM AWS
The first level of security then is controlling access to these services. For that AWS, has, but what else, an identity and access management system or IAM. It’s called — wait for it— IAM.
When I set up my first AWS account to use EC2, I was given root access and the ability to add new users and groups. You can think of these additional users as power users who can create and modify services in the AWS console. They’re the elite admins of the AWS cloud world.
Users can be organized into groups. And if you’re wondering where the access part of IAM, it’s through something called policies. We wrote a little about these JSON-structured things with respect to S3 buckets.
Just as you can associate a policy with a bucket, you can do the same with IAM users. I’ll talk about setting policies for AWS console users in the next post, but let’s say that the Amazon policies ain’t very intuitive.
In my scenario, I set up a policy for an IAM group called Restricted, which allows users only read access to the EC2 part of the AWS — in other words, preventing them from launching or stopping Amazon instances. I added two users into the Restricted group: sleazysal and sneakysam.
By the way, there are additional security protections that Amazon provides for AWS users, including multi-factor authentication — currently supporting only special hardware fobs — and separate security credentials that, as we’ll see, can be used to access Amazon services from within computing environment through AWS’s special command line interface or cli.
Next time we’ll learn more about the not very pretty details of policies and something called Amazon resource names or arns, which is the way you refer to just about everything in the Amazon-verse.
Keep in mind that IAM covers users at the level of the AWS console. To set up ordinary users and their permissions, you’ll need to work with plain vanilla directory environments, such as Active Directory, which will examine next time through AWS Directory services.
The AWS console really a portal for admins to launch EC2 instances and other computing environments, set up buckets, create databases, and of course monitor activities.
AWS does support auditing of AWS services and this is done through their CloudTrail service. You can think of it as something like Microsoft’s Event Log, but not nearly as pretty—hard to believe, I know! Further on in this series, we’ll learn about Amazon Athena, which is a tool to help you tame the raw Amazon event logs.
It’s a good time to look at a service that provides a useful real-world application, S3 buckets. Buckets have obvious use cases in storing huge image files for web applications, but it can store any corporate big-data file.
Or in the scenario I worked out, you can think of buckets as a bare-bones file locker (below).
However, more appropriate for this type of file sharing activity is the Amazon Workdocs service, which we’ll explore next time.
In any case, with S3 buckets you can configure access control lists for different IAM users. And for more sophisticated permissioning, you can also up more granular policies.
By the way, it’s relatively easy to upload files and other digital objects into the S3 buckets using the Amazon browser interface. There are even third-party apps, one of which I experimented with, that turn this into more of a file locking and sync service.
What about monitoring and auditing bucket resources?
Amazon does offer a service called Macie, which it describes as “using machine learning to automatically discover, classify, and protect sensitive data in AWS”.
After reviewing Macie, I’d say it’s a data classification service with an alerting function, kind of something like this and this. You could envision, say, some corporate application monthly uploading huge amounts of transactional data from several different locations into an Amazon S3 bucket. Macie would then monitor the bucket data and let you know who’s accessing it as well as alerting when it finds sensitive PII.
Macie has the ability to let you set regular expressions to discover PII patterns, and to classify text using static strings — for example, find the word “proprietary” or “confidential” in a document.
I’ll make the point again that Amazon’s built-in tools are not the most informative or easy-to-use. At a minimum, Macie gives you some insights into the Amazon bucket data store.
We’ll see later that it is possible to import S3 bucket objects, using the Amazon command line interface, into a standard Windows environment. And from there, with the right tools, you can do a far better analysis.
Let’s take a breath.
We’ve laid out some of the basics of the AWS environment, and looked at a few security and auditing ideas. Next time will take closer look at some of these AWS security tools.
And then we’ll start getting into more of the meat, by examining practical IT environments — particularly Workspace and Workdocs — and see what Amazon offers in terms of security.
(Spoiler alert: there ain’t much beyond standard Windows functions.)
Till next time!