-->

aws ,  security cloudtrail, audit

Another important service under Management & Governance category is CloudTrail.

A nice thing about this service is that it’s already enabled by default with a limited capacity. You can view all AWS API calls made in your account within the last 90 days. This is completely free and enabled out of the box.

To get more out of CloudTrail we need to create trails

Inside Trails

A couple of options about trails:

  • It can apply to all regions
  • It can apply to all accounts in an organization
  • It can record all management events
  • It can record data events from S3 and Lambda functions

Just be mindful about the possible extra charges when you log every event for all organization accounts:

Testing the logs

I created a trail that logs all events for all organization accounts. I created an IAM user in another account in the organization. In the event history of the local account events look like this:

These events now can be tracked from master account as well. In the S3 bucket these events are organized by account id and date and they are stored in JSON format:

Conclusion

Having a central storage of all events in across all regions and accounts is a great tool to have. Having the raw data is a good start but making sense of that data is even more important. I’ll keep on exploring CloudTrail and getting more out of it to harden my accounts.

Resources

aws ,  security aws_config, audit

In my previos blog post I talked about creating an IAM admin user and using that instead of root user all the time. Applying such best practices is a good idea which also begs the question: How can I enforce these rules?

AWS Config

The official description of the service is: “AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources”

What this means is you select some pre-defined rules or implement your custom rules and AWS config constantly runs checks against your resources and notify you if you have non-compliant resources.

Since currently I’m interested in hardening IAM users in the next example I’m going to use an IAM check

Use case: Enforcing MFA

As of this writing there are 80 managed config rules. To enforce MFA, I simply searched MFA in the “Add rule” anf got 5 matches of which I selected only 3:

After I accepted the default settings it was able to identify my IAM user without MFA:

And it comes with a nice little dashboard that shows all your non-compliant resources:

It also supports notifications via SNS. It creates a topic and all you have to do is subscribe to that via an email address and after confirming your address you can start receiving emails.

I was only expecting to get emails about non-compliant resources but it’s bit noisy as it sends emails with subjects “Configuration History Delivery Completed” or “Configuration Snapshot Delivery Started” which didn’t mean much to me.

Pricing

I think the price is exteremely high. The details can be found on their pricing page but in a nutshell a single rule costs $2/month. So for the above example I paid $6 which is a lot of money in terms of resources used.

Conclusion

I like the idea of having an auditing system with notifications but for this price I don’t think I will use it.

I will keep on exploring though as I’m keen on implementing my custom rules with AWS config and also implementing them without AWS config and see if this service adds any benefit over having scheduled Lambda functions.

Resources

aws ,  security iam, best_practices

When you create a new AWS account you are the root user who has unlimited access to everything. Using such a powerful user as root on a day-to-day basis is not such a good idea because if it gets compromised you may not have a way to override and/or undo the changes done by the hacker.

Using IAM user instead of root account

Instead, suggested best practice is to create an admin-level IAM account and use it for normal operations. At first I was hesitant to adopt this practice. I didn’t see the point and thought attaching AdministratorAccess policy awould make the use as powerful as root. But there’s a whole list of things that even the most powerful IAM user cannot do. Here’s the list: AWS Tasks That Require AWS Account Root User Credentials

So as you can see root user has important privileges such as closing the account and changing billing information. Even if your account gets compromised and some mailicous person gains access using an IAM account, you can still log in as root and take necessary action.

In a nutshell, based on AWS documentation the following practices are recommended:

  • Use the root user only to create your first IAM user
  • Create an IAM user for yourself as well, give that user administrative permissions, and use that IAM user for all your work.

In addition to Eric Hammond suggests in his blog to delete the root account password as well and use Forgot Password option to create a new one when needed. I keep my passwords in a password manager so if that application is compromised, the hacker can reset my password as well so I don’t follow this practice but it might come in handy if you have to write your password down somewhere.

Templated IAM user creation

It’s a good practice to create an IAM user right after you create your AWS account. It’s even a better practice to automate this process. To achieve this I created a CloudFormation template. The YAML template below does the following:

  • Creates an IAM group named administrators
  • Creates a user named admin
  • Attaches AdministratorAccess policy to the group
  • Forces the user to change their password first time they log in (by attaching IAMUserChangePassword policy to the user)
Resources:
  AdministratorsGroup:
    Type: AWS::IAM::Group
    Properties:
      GroupName: "administrators"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess
      Path: /

  AdminUser:
    Type: AWS::IAM::User
    Properties: 
      Groups:
        - !Ref AdministratorsGroup
      LoginProfile:
        Password: "CHANGE_THIS"
        PasswordResetRequired: true
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/IAMUserChangePassword
      Path: /
      UserName: "admin"

Resources