Security and Cloud 24/7

Archive for the ‘AWS’ Category

When using public cloud services for relational databases, you have two options:

• IaaS solution – Install a database server on top of a virtual machine
• PaaS solution – Connect to a managed database service

In the traditional data center, organizations had to maintain the operating system and the database by themselves.

The benefits are very clear – full control over the entire stack.

The downside – The organization needs to maintain availability, license cost and security (access control, patch level, hardening, auditing, etc.)

Today, all the major public cloud vendors offer managed services for databases in the cloud.

To connect to the database and begin working, all a customer needs is a DNS name, port number and credentials.

The benefits of a managed database service are:

• Easy administration – No need to maintain the operating system (including patch level for the OS and for the database, system hardening, backup, etc.)
• Scalability – The number of virtual machines in the cluster will grow automatically according to load, in addition to the storage space required for the data
• High availability – The cluster can be configured to span across multiple availability zones (physical data centers)
• Performance – Usually the cloud provider installs the database on SSD storage
• Security – Encryption at rest and in transit
• Monitoring – Built-in the service
• Cost – Pay only for what you use

Not all features available on the on-premises version of the database are available on the PaaS version, and not all common databases are available as managed service of the major cloud providers.

Amazon RDS

Amazon managed services currently (as of April 2018) supports the following database engines:

• Microsoft SQL Server (2008 R2, 2012, 2014, 2016, and 2017)
  Amazon RDS for SQL Server FAQs:
  https://aws.amazon.com/rds/sqlserver/faqs
  Known limitations:
  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureSupport.Limits
  
• MySQL (5.5, 5.6 and 5.7)
  Amazon RDS for MySQL FAQs:
  https://aws.amazon.com/rds/mysql/faqs
  Known limitations:
  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.KnownIssuesAndLimitations.html
  
• Oracle (11.2 and 12c)
  Amazon RDS for Oracle Database FAQs:
  https://aws.amazon.com/rds/oracle/faqs
  Known limitations:
  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
  
• PostgreSQL (9.3, 9.4, 9.5, and 9.6)
  Amazon RDS for PostgreSQL FAQs:
  https://aws.amazon.com/rds/postgresql/faqs
  Known limitations:
  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.Limits
  
• MariaDB (10.2)
  Amazon RDS for MariaDB FAQs:
  https://aws.amazon.com/rds/mariadb/faqs
  Known limitations:
  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html

Azure Managed databases

Microsoft Azure managed database services currently (as of April 2018) support the following database engines:

• Azure SQL Database
  Technical overview:
  https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview
  Known limitations:
  https://docs.microsoft.com/en-us/azure/sql-database/sql-database-dtu-resource-limits
  
• MySQL (5.6 and 5.7)
  Technical overview:
  https://docs.microsoft.com/en-us/azure/mysql/overview
  Known limitations:
  https://docs.microsoft.com/en-us/azure/mysql/concepts-limits
  
• PostgreSQL (9.5, and 9.6)
  Technical overview:
  https://docs.microsoft.com/en-us/azure/postgresql/overview
  Known limitations:
  https://docs.microsoft.com/en-us/azure/postgresql/concepts-limits

Google Cloud SQL

Google managed database services currently (as of April 2018) support the following database engines:

• MySQL (5.6 and 5.7)
  Product documentation:
  https://cloud.google.com/sql/docs/mysql
  Known limitations:
  https://cloud.google.com/sql/docs/mysql/known-issues
  
• PostgreSQL (9.6)
  Product documentation:
  https://cloud.google.com/sql/docs/postgres
  Known limitations:
  https://cloud.google.com/sql/docs/postgres/known-issues

Oracle Database Cloud Service

Oracle managed database services currently (as of April 2018) support the following database engines:

• Oracle (11g and 12c)
  Product documentation:
  https://cloud.oracle.com/en_US/database/features
  Known issues:
  https://docs.oracle.com/en/cloud/paas/database-dbaas-cloud/kidbr/index.html#KIDBR109
  
• MySQL (5.7)
  Product documentation:
  https://cloud.oracle.com/en_US/mysql/features

When working with cloud service providers, you may notice that at some point there are service / quota limitations.

Some limits are per account / subscription; some of them are per region and some limits are per pricing tier (free tier vs billable).

Here are some of the most common reasons for service / quota limitations:

• Performance issues on the cloud provider’s side – loading a lot of virtual machines on the same data center requires a lot of resources from the cloud provider
• Avoiding spikes in usage – protect from a situation where one customer consumes a lot of resources that might affect other customers and might eventually cause denial of service

For more information about default cloud service limits, see:

• AWS Service Limits:
  https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html
• Azure subscription and service limits, quotas, and constraints:
  https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits
• Google App Engine Quotas:
  https://cloud.google.com/appengine/quotas
• Oracle Cloud Service Limits:
  https://docs.us-phoenix-1.oraclecloud.com/Content/General/Concepts/servicelimits.htm

Default limitations can be changed by contacting the cloud service provider’s support and requesting a change to the default limitation.

For instructions on how to change the service limitations, see:

• How do I manage my AWS service limits?
  https://aws.amazon.com/premiumsupport/knowledge-center/manage-service-limits/
• Understanding Azure Limits and Increases
  https://azure.microsoft.com/en-us/blog/azure-limits-quotas-increase-requests/
• Google Resource Quotas
  https://cloud.google.com/compute/quotas#request_quotas
• Oracle Cloud – Requesting a Service Limit Increase
  https://docs.us-phoenix-1.oraclecloud.com/Content/General/Concepts/servicelimits.htm#three

AWS access keys enable us to use programmatic or AWS CLI services in a manner similar to using a username and password.

AWS access keys have account privileges – for better and for worse.

For example, if you save access keys (credentials) of a root account inside code, anyone who uses this code can totally damage your AWS account.

Many stories have been published about security breaches due to access key exposure, especially combined with open source version control systems such as GitHub and GitLab.

In order to avoid security breaches, here is a list of best practices for securing your environment when using access keys:

• Avoid using access keys for the root account. In case you already created access keys, delete them.
  https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials
• Use minimum privileges when creating account roles.
  https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html
• Use AWS IAM roles instead of using access keys, for resources such as Amazon EC2 instance.
  https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html
• Use different access keys for each application, in-order to minimize the risk of credential exposure.
  https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
• Protect access keys by storing them on encrypted machines or encrypted volumes, and avoid sending access keys via email or any other insecure medium.
  https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html
• Rotate (change) access keys on a regular basis, to avoid reuse of credentials.
  https://aws.amazon.com/blogs/security/how-to-rotate-access-keys-for-iam-users/
• Remove unused access keys, to avoid unnecessary access.
  https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html
• Use MFA (Multi-factor authentication) for privileged operations/accounts.
  https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html
• Configure billing alerts using Amazon CloudWatch, to get notifications about anomaly operations in your AWS account.
  https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/monitor-charges.html
• Use AWS CloudTrail auditing to review when was an access key was last used.
  https://aws.amazon.com/blogs/security/new-in-iam-quickly-identify-when-an-access-key-was-last-used/
• Use open source tools such as git-secrets to avoid storing passwords and sensitive information inside a GIT repository.
  https://github.com/awslabs/git-secrets
• Work according to GitHub recommendations and avoid using sensitive information in a public repository.
  https://help.github.com/articles/removing-sensitive-data-from-a-repository/