AWS Account Structure and IAM

NYU Account Structure and IAM Overview Account structure provides the basis for solid and simple application of security and organizational directives from the top level of NYU, and enforcing those rules appropriately for the entire organization. Accordingly, is it an important topic. Policies laid out here are intended to be broad and flexible enough to […]

NYU Account Structure and IAM Overview

Account structure provides the basis for solid and simple application of security and organizational directives from the top level of NYU, and enforcing those rules appropriately for the entire organization. Accordingly, is it an important topic.

Policies laid out here are intended to be broad and flexible enough to address the majority of issues, but the intent is that as the organization grows and changes, those changes will be reflected in updates to this document and related processes and procedures.

Account Structure

NYU IT has implemented a simple and direct layout of our accounts. There is a single top-level account, the Master Account. The shared services are provided through the Shared Services / Production Account, and all other accounts are sub accounts, inheriting permissions and policies, and having access to shared services provided to the organization as a whole, which are provided by that Master Account.

Figure 1: NYU’s AWS Account Structure for Accounts and VPCs

NYU's AWS Account Structure for Accounts and VPCs

Shared Service Examples

Currently Available

  • Billing and accounting
  • Financial reporting, using a tool such as CloudTrail,
  • Monitoring, Reporting, Finance and Stability tools such as CloudHealth, CloudCheckr (third-party)
  • Golden AMIs
  • Patching and system updating
  • Monitoring and alerting on outages, high/low usage alerting, uptime, etc

Future Offerings

  • Service Catalog
  • Security scanning, auditing and the like
  • Virus scanning, definitions, and reporting
  • Source Code repositories
  • Automated Development or DevOps Tools
  • Common installation files
  • Hosted COTS or SaaS products

Notes:

  • Some services cannot be used by a lower account unless enabled on the top-level account. Example: AWS Single-Sign-On Product.
  • Most services will require manual configuration, and granting of access in order to function

Setting and Enforcing Policy

Policies & Permissions Setting and Enforcement
Policies for the organization can and should be set at the MAaster Account level, and inherited and enforced throughout the AWS implementation for NYU. As the organization chooses, this can include exempting or requiring acceptance at a policy by policy level.

Suggested Policies for Enforcement on All Accounts

  • Root account ownership
  • Admin account management
  • Billing and accounting
  • Cost reporting
  • Ability to scan all services enabled or in use
    • Example scans might include security or PII scanning
  • Exception monitoring
  • Virus scanning
  • Patching policies
  • Security policies

A sub account owner may be allowed to opt out to some or all of these policies, if they provide their own accepted policy. Auditing would still be needed to ensure enforcement of those policies. Generally these policies would be reviewed and approved by the Cloud Architecture Review Board and results would be documented.

NYU’s ownership of the root account protects the organization from loss of the account should an employee leave the organization, become unavailable through sickness or death, or even decide to act maliciously. In such cases, the account can be controlled and ownership retained.

Billing

All NYU billing shall be consolidated under this single Master Account. Costs will be allocated using existing accounting practices for tracking, reporting and billing back, and will be pulled using either built-in AWS billing and account reporting tools such as CloudTrail and CloudWatch, or use those in combination with use of a third-party tool such as CloudCheckr.

Adding Account to Master

To be added to the master account, accounts will need to go through an on-boarding process.

  • Root account will be taken over and managed centrally
  • Core policies will be applied to the sub-account
  • Analysis and action to exempt sub-accounts from appropriate policies. Preference is to limit this as much as possible, and perhaps enforce a rule to prevent access to shared NYU services and systems unless core policies are enabled
  • Accounts created for use and management of the new account, using the standard SSO or inherited access from the Master Account

Exceptions to policy will be noted, along with justification in NYU’s Confluence Wiki. Compensating controls or policies should be noted here as well.