AWS Security Checklist

AWS Security Checklist

If you are not using a particular service (e.g. S3, Cognito, etc.), their corresponding security practices will not apply.


Managing the Account

  • When starting a new project, reach out to UCF GRIT to create an AWS account through the Research IT AWS organization. This simplifies the onboarding process and provides access to features like:
    • SSO (convenient for users with access to many AWS accounts)
    • Context-based MFA
    • Self-service password reset
    • Access to Research IT VPC (this is necessary for some of the items below)
    • GuardDuty enabled by default to monitor suspicious activity
  • The account will also be created under the AWS-UCF agreement with data egress waiver and tax exemption configured from day zero
  • If you are using an existing AWS account, move it under this organization

Improving Security

  • Do not share root user. Instead, create an IAM user (with MFA configured) for every person who has access to the AWS account.
  • Do not embed AWS access keys in the application´s code. It´s common to forget about it and publish the keys on a public git repository allowing anyone to access the account.
  • Deactivate any IAM user access keys that are not in use (or delete them if never expected to be used), especially users with admin access
  • Trim down IAM role permissions to achieve least privilege access (only allow a particular service access to what it requires, nothing more)
  • For applications that need to connect to a relational database, create a user/login in the database specific to the app, and grant only the required access to perform the job
  • For applications running on EC2 that need access to AWS services, use an IAM role attached to the instance instead of IAM access keys
  • Do not open EC2 security groups to the world unless you are hosting a web application facing internet. Use AWS Session Manager service to privately access instances through SSH, private web applications, and RDS databases.
  • Create one IAM role per Lambda function (this should be default behavior)
  • Move RDS databases, and everything that touches them, into a VPC
    • If Lambda functions need both database and internet access, use the UCF IT shared network to save money on NAT gateways/PrivateLink
  • Encrypt Lambda environment variables to achieve at-rest and in-transit encryption on sensitive information (e.g. database passwords, API keys, etc.)
    • If Lambda functions are also accessing the database (or otherwise need to be in a VPC), use the UCF IT shared network to accomplish this
  • Encrypt and remove public access from RDS databases
  • Encrypt and remove public access from S3 buckets
  • Consider configuring Versioning on S3 buckets to prevent data loss
  • Configure password policy in Cognito to match UCF´s password policy:
  • Restrict non-user access to API endpoints, and only allow users to access their own data using Authorizers in API Gateway
  • Use stored procedures in SQL databases (not AWS-specific, but prevents SQL injection)
  • Configure backups using AWS Backup service:

Saving Money

  • Configure budget alerts to prevent unexpected charges
  • Stop any DEV database(s) and EC2 instance(s) when not in use
    • From AWS documentation: “You can stop a DB instance for up to seven days. If you don’t manually start your DB instance after seven days, your DB instance is automatically started so that it doesn’t fall behind any required maintenance updates.”
  • EBS volumes generate charges when associated EC2 instances are stopped or the volumes are detached. Create a snapshot and delete EBS volumes that you don´t need.
  • Make sure databases are in the same AZs as corresponding EC2 instances to prevent regional data transfer charges
  • Use the AWS Calculator tool to understand how pricing works on one particular service and estimate cost:
  • EC2 instances running on-demand are the most expensive ones. Consider spot instances for ML training workloads and batch processing, and buy a Saving Plan when a commitment for a 1- to 3- year period is possible.

Data Classification

UCF highly restricted data classification can be supported in AWS, taking care of access control to the data, security of the applications and servers, and implementing encryption at rest as well as in-transit.

Below is side by side the definitions from policy; To help to compare the two:

UCF – Highly Restricted UCF – Restricted
must be stored it in an encrypted form on a secure UCF server, with access protected by a strong password; can be stored on workstations or mobile computing devices if the devices are protected by a strong password. File level encryption is required. Full disk encryption is recommended. May be placed only in a UCF-sanctioned Internet cloud data storage system, but not in a personal cloud data storage system;
must have full disk encryption using current industry standards if highly restricted data must be stored on desktop workstations in conjunction with official university business processes;
must never be stored on mobile devices such as laptops, tablets, smartphones, or USB drives;
may be placed only in a UCF-sanctioned Internet cloud data storage system intended for highly restricted data, but not in personal cloud data storage accounts;
must not be posted on any public website, blog, or other publicly-accessible Internet site; must not be posted on any public website, blog, or other publicly-accessible Internet site;
must not be sent via electronic mail, or in an email attachment unless encrypted using current industry standards; may be sent to users who are within a university-provided email system (e.g., UCF Exchange, Knights email, Webcourses@UCF). May be sent to recipients who use external email systems if encrypted using current industry standards;
must not be sent via instant messaging or other unencrypted applications; instant messaging of restricted data between faculty, staff, and students must be through a university-provided instant messaging system, (i.e., Lync or Skype for Business). Instant messaging may not be used to send restricted data to external systems;
must always be protected by using a secure connection method, such as a VPN and/or SSL/TLS when transmitted through a data network;
must be stored in a locked cabinet or drawer in a location where access is controlled by a lock or card reader, or that otherwise restricts access to only authorized persons when in hard copy format;
must not be disclosed to third parties without explicit management authorization and then only on a need-to-know basis;
must be sent only to a known number when sent via fax; must be sent only to a known number when sending via fax;
must be destroyed when no longer needed, subject to the State of Florida General Records Schedule and UCF policy 4-010. must be destroyed when no longer needed, subject to the State of Florida General Records Schedule and UCF policy 4-010.