1 of 33

AWS Account Governance & Management

2 of 33

Who are we?

  • James Smith
    • Cloud Architect (Former Information Security Architect)
    • Working with AWS since 2013
    • Contact: jsmith68@nd.edu

​

  • Jared Bulosan
    • Information Security Architect (Former IAM Engineer)
    • Working with AWS since 2014
    • Contact: jbulosan@nd.edu

3 of 33

Where did we start?

One primary AWS account containing entire datacenter

4 of 33

Early Pain Points

IAM (Identity & Access Management) Policies

​

  • Switched to overly permissive IAM policies
  • Started with overly restrictive IAM policies

5 of 33

Early Pain Points

​

  • Root account management
    • Cloud Platform team manages passwords in password manager (Good)
    • Information Security team maintained physical MFA fobs in a safe (Not so good)

​

Stemmed from our separation of duties requirement

​

6 of 33

Separation of Duties

Engineer

Infosec

7 of 33

When do we use Separation of Duties?

  • Terminating production EC2 & RDS instances

Significant actions:

  • Modifying most IAM resources
  • Removing major production networking resources
  • Accessing root and privileged accounts

8 of 33

Why Separation of Duties?

To prevent large-scale negative impacts from:

Hackers

Insider Threats

Human Error

9 of 33

Early Pain Points (continued..)

  • Logging and auditing
    • Lack of defined requirements
    • Lack of consolidation
  • Inconsistent configurations across accounts
    • No baseline configurations for central or other IT groups
    • Different it organizations had their own AWS accounts
      • All configured in a different way
  • Lack of central user account management
    • Local users in every account

10 of 33

Where are we now:

​

  • We utilize native tools from AWS to ease governance and improve security
  • Some custom tools allow for integration with SaaS providers or ease management
    • Service Now
    • Fireeye

11 of 33

Where are we now:

​

  • Converted to a multi-account strategy
    • Easier IAM policy management
    • Natural permission boundaries
      • Limit the blast radius
    • Makes auditing easier
    • Easier billing

12 of 33

Tools we utilize

  • Organizations

Honorable Mentions:

  • SNS, SQS, S3, Lambda, KMS, Secrets Manager, AWS Config, Guard Duty, Cloudwatch, Cloudtrail
  • Cloudformation
  • IAM SSO Federation with Okta
  • Custom MFA tool for privileged accounts

13 of 33

Organizations

14 of 33

Organizations

  • What is Organizations?
    • An AWS Service for central management across multiple AWS accounts
  • Benefits
    • Central Billing
    • Create new accounts (Standard & GovCloud)
    • Create OU’s
    • Apply service control policies
      • Deny IAM actions at OU level
    • Enable services at a global account level
      • Cloudtrail
      • Config

15 of 33

Organizations

  • Global Cloudtrail Example (Linked Account)
    • Notice anything?

​

16 of 33

Organizations

  • Service Control Policies
    • Limit regions, instances sizes/families, whole services, plus more

17 of 33

Organizations

18 of 33

IAM SSO Federation with Okta

19 of 33

AWS IAM Before Federation

  • Local IAM management in each account
  • Stale user lifecycle management
  • Separate credentials for each user

20 of 33

AWS IAM After Federation

  • Centralized account management
  • Automatic lifecycle management
  • Enterprise credentials for each role

21 of 33

Federation Obstacles

What about separation of duties?

  • Privileged accounts cannot be federated

What if SSO goes down?

  • Maintain emergency backdoor

22 of 33

Cloudformation

23 of 33

Cloudformation

Allows us to build infrastructure as code

  • Provides uniform configurations from predefined templates.
  • Called Cloudformation “Stacks”
  • Built using .YAML files

​

24 of 33

Cloudformation Stack Sets

  • Allows for deployment of “stacks” from a central account.
  • Useful for common configurations across multiple accounts
    • SSO Federation
      • IDP
      • Roles
    • Security Baselines
      • Enabling GuardDuty
      • Cloudwatch Rules
    • Billing tools
      • Budget alarms

​

25 of 33

Cloudwatch Setup

​

  • Event Bus to send all API and Guard Duty events to a central security account
  • Cloudwatch rules in central security account for alerting
  • Alerts trigger incidents in ServiceNow

​

26 of 33

Custom MFA tool for privileged accounts

27 of 33

Why do we need it?

​

What happens when nobody is near the physical MFA fobs?

28 of 33

Serverless MFA Token Generator

123456

123456

29 of 33

How does it work?

30 of 33

How does it work?

31 of 33

Next Steps

  • Web-interface/API and Parameter Store for MFA Token Generator
  • Streamline IAM processes in Okta

32 of 33

Next Steps

  • More integrations with ServiceNow for:
    • Account generation (Account vending machine)
    • Resource requests (EC2 instances, S3 buckets, etc)
  • AWS Control Tower
    • Does not currently support existing Organizations
      • Waiting until it does

33 of 33

Questions?