Skip to main content

Guidelines for Cloud Computing

In order to support secure and effective use of cloud resources at Northwestern, Northwestern IT maintains this set of guidelines for operation of public cloud services accounts.

While the existing policies regarding server security, data access, and data encryption, among others, are applicable to cloud environments, there are specific considerations for cloud as well as tools and services available that can be leveraged to support the maintenance of compliant environments.

Audience:

Information technology staff, researchers, and research staff using cloud services.

Policy Statement:

The Northwestern Cloud Shared Responsibility Model

Cloud service providers generally employ a "shared responsibility" model, in which the service provider is responsible for the security "of" the cloud, and the customer is responsible for security "in" the cloud. This makes clear that while the tools and services are available to run secure workloads in the cloud, the customer is responsible for adapting and configuring the appropriate tools for their use case.

Northwestern extends this model to make a distinction between the responsibilities borne by the Northwestern IT cloud operations group and the cloud account owner.

The responsibilities are broken down broadly as follows:

Northwestern IT
  • Provision new cloud accounts with best practices security controls pre-implemented (e.g. identity federation, permissions guardrails, activity logging, security event notification, resource tagging, etc.)
  • Implement and maintain controls & guardrails across accounts
  • Implement security incident and cost anomaly detection and notification across accounts
  • Respond to new security events in cloud accounts
  • Maintain incident response documentation, playbook, and post-mortem reports
  • Facilitate periodic security audit of cloud accounts and share results with account owners
Account Owner/Operator
  • Utilize centrally provisioned resources (e.g. virtual private networks and network security groups, machine images) whenever possible
  • Keep patch level of workload environment up to date
  • Use best practices for account access (e.g. temporary credentials and role access rather than long-lived access keys or credential sharing) whenever possible
  • Participate in periodic security audit
  • Respond to findings of potential security incidents in a timely manner
  • Maintain data redundancy/backups as appropriate
  • Keep Northwestern IT appraised of any changes in account ownership/contacts, billing processes, or upcoming major projects that will require Northwestern IT involvement

Note: The above list is not exhaustive and may change over time.

Required and Recommended Cloud Security Controls

The controls listed below are within the scope of Northwestern’s implementation of cloud policy and governance. These controls are in alignment with Northwestern IT’s Server Security Requirements and related policies, public cloud best practices, the Northwestern cloud shared responsibility model, and the feedback of key partners within Northwestern University.

These controls are intended to empower account holders in the areas of security and governance (including auditing, change management, and cost management). The Northwestern IT Cloud Operations group will continually assess and improve its support for account owners in implementing these controls. This may include automatically enabling them in some cases or offering centrally-provisioned, pre-built resources in cloud accounts to make implementation easier.

All Northwestern AWS account holders must implement the "Required" controls to be considered compliant. It is expected that most, if not all, account holders will go beyond this required set and implement the "Recommended" set as well.

Controls

Required Controls
ID Governance Objective
Required Controls
1 Manage account sprawl, increase visibility All accounts must be provisioned as a child of the master organization account.
2 Prevent unauthorized access, protect sensitive data Administrative access to cloud resources should be granted only to those who have a business need, and access should be removed immediately upon a users’ departure. Admin access groups should be audited regularly.
3 Prevent unauthorized access, protect sensitive data User accounts with access to root privileges must have MFA enabled.
4 Protect sensitive data All data volumes and storage accounts must be tagged with approved data sensitivity classification (e.g. “Public”, “Internal”, “Legally/Contractually Restricted”).
5 Prevent unauthorized access, protect sensitive data Virtual networks must not peer with virtual networks in non-Northwestern accounts.
6 Attribute costs accurately, increase visibility All resources must be labeled with approved Project, Owner, and Environment tags.
7 Protect sensitive data, increase visibility Compute instances must have a monitoring or management agent installed. (Note cloud vendor-native agents such as EC2 Systems Manager are acceptable, as are 3rd party agents/services)
8 Prevent unauthorized access, protect sensitive data Compute instances must not have a public network interface unless required for business needs.
9 Prevent unauthorized access, protect sensitive data Storage accounts and volumes must not be configured to allow public access unless required for business needs.
10

Track resource utilization to ensure compliance with standards

Activity logging must be turned on for all resources and services
Recommended Controls
ID Governance Objective
Recommended Controls
11 Prevent unauthorized access, protect sensitive data VM firewalls and network security groups should have only authorized ports[1] open. Certain ports are only authorized to receive traffic from approved networks.
12 Prevent unauthorized access, protect sensitive data User, network, and compute instance access privileges should follow least-privilege principle.
13

Track resource utilization to ensure efficient usage

Resource diagnostics with logs and metrics should be enabled for all compute resources.
14 Prevent unauthorized access, protect sensitive data Console access should occur only via federated, NetID-based authentication with MFA enabled.
15 Prevent unauthorized access, protect sensitive data CLI access should use temporary access credentials with MFA enabled.
16 Minimize wasteful resource spending Elastic IP addresses, storage volumes, and other instance-related resources not associated with a running instance should be released or deleted.

[1] For example, only TCP ports 80 and 443 (HTTP, HTTPS) should be open to the world. TCP 22 (SSH) and TCP 3389/UDP 3389 (Microsoft Remote Desktop Protocol) should only be open to Northwestern-owned subnets.

 

Services and Tools

The following describes the services and tools available for implementing required and recommended controls for accounts owned by Northwestern-affiliated IT departments, business units, and research groups.

AWS
ID Control
Recommended Implementation
1 All accounts must be provisioned as a child of the master organization account. To request a new AWS account under the Northwestern contract, fill out the Public Cloud Account Request Form.
2 Administrative access to cloud resources should be granted only to those who have a business need, and access should be removed immediately upon a users’ departure.  Admin access groups should be audited regularly. Utilize federated login roles via SAML federation with Northwestern ADS security groups. Audit ADS security group membership annually.
3 User accounts with access to root privileges must have MFA enabled. Utilize federated login roles via SAML federation with Northwestern ADS security groups.
4 All data volumes and storage accounts must be tagged with approved data sensitivity classification (e.g. “Sensitive”, “Non-sensitive”, “HIPAA”). Tag S3 objects and EBS volumes with a key such as “Classification” and value of “Public”, “Internal”, or “Legally/Contractually Restricted”.
5 Virtual networks must not peer with virtual networks in non-Northwestern accounts. Do not initiate or accept peering requests from non-Northwestern AWS accounts.
6 All resources must be labeled with approved Project, Owner, and Environment tags. Assign a “Project” tag to each resource with the name of the associated project. Assign an “Owner” tag to each resource with the email address of the responsible party. Assign an “Environment” tag to each resource with a value of “Dev”, “Test”, “Staging”, or “Production”.
7 Compute instances must have a monitoring or management agent installed. Use the AWS Systems Manager for management and automation of EC2 and RDS instances.
8 Compute instances must not have a public network interface unless required for business needs. Do not assign a public IP address to compute instances unless required.
9 Storage accounts and volumes must not be configured to allow public access unless required for business needs. Block public access to all or selected S3 buckets at the account level, only permitting public access when absolutely necessary.
10 Activity logging must be turned on for all resources and services. Do not disable the NUIT_Support_CloudTrail trail that is created in your AWS account.
11 VM firewalls and network security groups should have only authorized ports open. Certain ports are only authorized to receive traffic from approved networks. Use EC2 Security Groups to allow network access on specific ports from specific IP ranges.
12 User, network, and compute instance access privileges should follow least-privilege principle. Do not use the Admin role to access your account unless necessary. Use federated roles or roles assigned to your compute instances with attached AWS IAM managed policies that provide access to only the services and actions required.
13 Resource diagnostics with logs and metrics should be enabled for all compute resources. Enable CloudWatch metrics and alarms to be alerted of application incidents. Certain AWS logs can be imported into Northwestern Splunk for analysis.
14 Console access should occur only via federated, NetID-based authentication with MFA enabled. Utilize federated login roles via SAML federation with Northwestern ADS security groups.
15 CLI access should use temporary access credentials with MFA enabled. Use a tool such as aws-adfs to generate temporary credentials for CLI access with IAM roles, with Duo MFA support.
16 Elastic IP addresses, storage volumes, and other instance-related resources not associated with a running instance should be released or deleted. Periodically audit your EBS volumes and Elastic IP address and remove unattached, unneeded resources.
Original Issue Date:

June 2020

Revision Dates:

February 2021

Additional Information:
Feedback and Process for Updates

The email distribution list cloud-policy@northwestern.edu is the official channel for feedback, questions, and suggestions about these guidelines for using cloud services at Northwestern.

The Northwestern IT Cloud Policy team commits to revisiting this document and any addenda quarterly, based on feedback from the community; new tools, services, and configuration settings made available by cloud vendors; direction from the Infrastructure Advisory Committee; and the needs of the university IT community.

Proposed changes will be posted to the Cloud Community of Practice Teams channel and announced on UNITS, with an appropriate period for comment from the community (generally two weeks), before being incorporated into the published guidelines.

Related Policies: Back to top