Design AWS API Access with Care – Case Onelogin

CATEGORIES

Tech

The recent Onelogin breach, shown here in their official blog post highlighted to us that account access permissions can be devastating if not done right.

From Kerbsonsecurity:

“Our review has shown that a threat actor obtained access to a set of AWS keys and used them to access the AWS API from an intermediate host with another, smaller service provider in the US. Evidence shows the attack started on May 31, 2017 around 2 am PST. Through the AWS API, the actor created several instances in our infrastructure to do reconnaissance. OneLogin staff was alerted of unusual database activity around 9 am PST and within minutes shut down the affected instance as well as the AWS keys that were used to create it.”

There are several ways to minimize the risk of a breach like this:

  • EC2 role-based access instead of API keys for services
  • SAML Identity and Access permissions for users
  • CLI IAM roles with Multi-factor authentication enforced for developers

The simplest way of minimising the risks is to avoid creating API keys for any application or user if possible. In AWS, you can create roles which can be applied to most services, such as EC2 instances and Lambda functions. The role-based permission model lets you specify least privilege with conditions. For example, all API calls have to originate from specified AWS accounts only. The access keys used for these API calls are temporary and only valid for a certain time. The nice thing for an AWS user is that this is transparent and you don’t have to manage the key rotation at all.

If your organisation currently has a user directory service then you can use SAML based federation for the users within your organisation. They will login to your organisation’s internal portal and will end up at the AWS Management Console without ever having to supply any AWS credentials. There are also third-party SAML solution providers which can be used to enable this.

Sometimes it might make more sense to manage the users within AWS. Make then sure that you delegate access across AWS accounts using IAM roles with Multi-factor authentication enforced in the access policy document. Multi-factor authentication (or two-factor authentication) is a simple best practice that adds an extra layer of protection on top of your username and password. With MFA enabled, when a user signs in or wants to use an API key, they will need to provide their access key and secret key (the first factor: what they know), as well as for an authentication code from their MFA device (the second factor: what they have). Taken together, these multiple factors provide increased security for your AWS resources.

With MFA enabled you will need to specify an AWS CLI configuration with the information about your MFA device. See this simple example for inspiration:

[profile loginaccount]

region = eu-west-1

source_profile = loginaccount

[profile dev]

region = eu-west-1

source_profile = loginaccount

role_arn = arn:aws:iam::xxxxx:role/Developer

mfa_serial = arn:aws:iam::xxxxx:mfa/foo@bar.com

[profile prod]

region = eu-west-1

source_profile = loginaccount

role_arn = arn:aws:iam::xxxxx:role/Developer

mfa_serial = arn:aws:iam::xxxxx:mfa/foo@bar.com

Then in the credentials file you have:

[loginaccount]

aws_access_key_id = AKXXXXXXXXXX

aws_secret_access_key = SUPERSECRETKEY

The only user within the organization is the one in the login account. To switch to another account, change the profile using the AWS CLI as such:

$ aws ec2 describe-instances --profile dev

or export the profile as an environment variable if you always want to use a specific account:

$ export AWS_DEFAULT_PROFILE=dev

Limes is an application that creates an easy workflow with MFA protected roles, temporary credentials and access to multiple roles/accounts.

Have a look if you have a lot of accounts or roles to manage.

It can be really hard to discover a breach. Onelogin were lucky that they saw the unusual database activity as fast as they did their own tests that have shown it takes between 2-15 minutes before someone starts using AWS API keys pushed to a GitHub repository. AWS themselves do look for published API keys in GitHub, but it might take up to 24 hours before they notify you of their finds.

An audit and security account is one solution to this problem. The audit account should have access to all cloud trail logs and constantly monitor for any unusual activity such as the creation of IAM users.

Need help securing your cloud? Nordcloud can help you with all of the points above as well as doing security audits and workshops. With your cloud trail logs monitored 24/7 by Nordcloud Managed Services Monitoring we can react with 30 minutes if an unauthorised API call is made.

Blog

Stop murdering “Agile”, and be agile instead

“Agile Macabre” on techcamp.hamburg, Apr-2020 I’ve been leading projects since 2002, becoming a full-blown agilist around 2011. Not so long...

Blog

Make Work Better by Documentation

Sharing knowledge in a team is an ongoing challenge. Finding balance between writing documentation and keeping it up to date,...

Blog

How can you maximize the value from your data?

Your market is changing in faster and less predictable ways than ever before. Enterprises of all sizes suffer from data...

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.








5 AWS services that help you create and monitor secure environments in the cloud

CATEGORIES

Insights

One typical concern when moving your infrastructure to Amazon Web Services is that you may lose control over it, but the truth is quite the opposite; AWS will take care of everything on the physical side of your infrastructure (while being compliant with basically every relevant certification and regulation) so you can focus on managing and monitoring the services that you use – and there are plenty of tools on AWS to do that.I will introduce five important services that are connected to managing security and monitoring your environment in the AWS Cloud. I won’t go too deep into details here but rather give an overview of these services and how they work together.

Virtual Private Cloud (VPC)

A Virtual Private Cloud (VPC) is your own private cloud inside AWS. Here you define all the networking details and manage how your instances can be accessed. You can use things like Route Tables and Network Access Control Lists to manage traffic flow in and out of (and within) your environment. In addition to EC2 instances, you can also put your relational databases (RDS) inside a VPC to make sure that they can only be accessed by your application servers. You have complete control over how your instances can be accessed and you can even limit this to a VPN connection from your on-premise environment. VPC has way too many features to be described in one blog post but you definitely want to learn to build VPCs as your first steps towards the AWS Cloud!

CloudWatch

Once you have deployed your instances to a VPC, you want to monitor them. CloudWatch is a service that automatically collects metrics from your infrastructure and also from basically every managed service that AWS has to offer. You can use this data to trigger alarms that can, for example, send you e-mails or launch more EC2 instances to an Auto Scaling group. You can view graphs of your metrics from the past two weeks in the CloudWatch console or send those metrics to 3rd party services like DataDog for further analysis. CloudWatch is one of the main tools to create automation for your infrastructure so that you don’t need to manually react to traffic peaks or issues in your environment.

CloudTrail

While CloudWatch is great for monitoring your infrastructure, it doesn’t track access to your AWS environment. CloudTrail is a service that you can enable per region and it will track all API calls (meaning all actions) that are done by your AWS users or roles. All of this data is stored in S3 and you can send it to CloudWatch Logs or 3rd party services for further analysis. CloudTrail will give you detailed information on who did what and when. This can also be very useful for audit purposes.

AWS Config

If CloudTrail is for tracking each and every action users make, then AWS Config is a service that will track the state of your environment. You will get detailed information on changes that are made to your resources and also reports on the state of your whole infrastructure. AWS Config provides point in time snapshots of your resources. You can also create Config Rules that are evaluated against changes in your resources and the rules can alert you on unwanted changes and possible security issues.

Simple Notification Service (SNS)

Simple Notification Service is a service that delivers messages to subscribers. It is widely used by other AWS services, including the ones listed here, to send you notifications on things that happen in your environment. You can use it together with alarms that you create in CloudWatch to get notifications when an alarm is triggered. You create Topics and publish messages to these Topics. A Topic can have multiple subscribers that will receive all messages published to the Topic. The subscribers can be a number of things from HTTP endpoints to e-mail and Lambda functions.

Security in the cloud starts with good knowledge of your infrastructure and extensive monitoring. The services I have described here can be used to achieve just that. There is of course, a lot more to consider when talking about the security of your environment. If you would like to talk to Nordcloud more about your cloud environments, contact us here.

Blog

Time to rescue your data operations

The value created by data can fundamentally influence key areas of your business, from enabling, optimizing and steering key functions. ...

Blog

What it’s like to be a new hire during Covid-19

We all have been there before, the thrill of getting that call when your future manager makes the offer. You...

Blog

A Recruiter’s Perspective on Remote Work

In the times of the Coronavirus you can read a lot about ways of switching to the remote ways of...

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.