Nick Walter, Principal Architect

Oracle Security Best Practices in EC2 and RDS for the DBA

Many House of Brick customers who I speak to are very excited about the possibilities of running Oracle in AWS, either on EC2 or leveraging the AWS Relational Database Service (RDS).  That excitement is often tempered by the caution of moving to a new platform with many unknowns.  One of the big unknowns is security, and I see a lot of our customers experience difficulty in producing a sufficiently robust and well-documented security approach to satisfy internal security officers or external auditors.

While a full deep dive on the topic of Oracle security in the cloud would require a much longer format than this blog, I do think it would be valuable to share some of the experience House of Brick has gleaned from working with our customers on Oracle database deployments in AWS.

In order to maintain a properly secured Oracle EC2 or RDS instance in AWS, as per House of Brick best practices, it is important to consider all layers of security holistically.  This is in contrast to the traditional methods of ensuring security for an on-premises Oracle database, which have typically featured disparate teams handling different slices of the security pie.   With an on-premises Oracle database, typically there are network security considerations for network administrators, VM level concerns for virtualization administrators, system concerns for sysadmins, and database security concerns for DBAs.  Moving from such a siloed approach to security to a more holistic one is a definite challenge for a DBA who is experienced in securing only the database layer.

NETWORK

The first slice of the security pie to consider is network security.  Network security isn’t something that a DBA can simply ignore, or turn over to a network team when running in AWS, as the complexity and flexibility of cloud native applications demand more from the DBA.  A properly secured Oracle EC2 or RDS instance should be contained in a VPC and restricted to a private subnet group.  In addition, it should always be protected with a database-specific security group.  The security group should be configured according to the Principle of Least Privilege, so access is granted only to those specific application servers or subnet groups that require access.  The Oracle EC2 or RDS instance should never be configured with a public IP address with public accessibility.

AWS ACCOUNT

The next slice to consider is at the AWS account level.  An unauthorized user who gains access to the AWS account containing the database could potentially alter the admin credentials of the database, export data or backups, or even destroy the database.  Especially in RDS, where administrative access to the AWS account equates to administrative access over the database, it is impossible to secure a database properly without first securing the AWS account containing the database.  Therefore, House of Brick best practice is to secure the EC2 or RDS instance from both external user threats and internal user threats.

In order to properly secure the AWS account, the first step that any good security professional will recommend is to secure the root account and ensure that it is not being actively used.  The root account should only be accessed in dire need, so for all day-to-day operations individuals should be accessing the AWS environment using individual IAM accounts.  House of Brick best practice is for all accounts to be protected with both a strong password policy and multi-factor authentication (MFA) using either a physical or virtual MFA device.  Additionally, CloudTrail logging should always be enabled on the account to ensure an audit log of actions taken by users.

INSTANCE (EC2 or RDS)

Once the account is properly secured, attention must turn to the next slice of the pie, the instance.  For the sake of disentangling the confusion of AWS terminology versus Oracle terminology, I should clarify that in this context I’m referring to an EC2 or RDS instance.  Oracle EC2 or RDS instances should be secured by assigning appropriate policies to groups of users, or roles, that are authorized to access the instance.  These should be more restrictive than the permissions given to general application administrators.  The default AmazonRDSFullAccess policy provided by AWS is extremely broad and powerful, allowing full administrative access to all databases on an account, so House of Brick recommends crafting a more targeted policy.  By creating a custom policy, it is possible to grant restricted permissions that allow only certain actions, or limits access to specific databases.

It is also House of Brick best practice to define specific IAM roles for database administration and to require users to assume a role when performing administrative tasks.  The policies granting administrative access are then attached to the role. This allows a clean separation of authority over production versus non-production, or certain applications versus other applications and simplifies administration by keeping the policies centralized to various roles.  In addition, requiring different roles for production versus non-production databases helps prevent human error.  A user signed into a non-production privileged role cannot accidentally change or harm production systems, as they simply lack the rights to do so.

DATABASE

The database slice of the pie should be most familiar to DBAs, so I will avoid going into deep detail here.  All of the traditional best practices for securing an Oracle database, such as rotating passwords on accounts regularly, keeping current on security patches, and using the Principle of Least Access for database level accounts all still apply.  It should be noted that RDS has a strong advantage here as AWS automatically secures the instance and handles patch deploy for users.

BACKUP

The final slice of the database security pie to address is Backup security.  This requires special attention in AWS as the S3 service is far and away the most popular means of storing database backups.  For all of S3’s virtues as an inexpensive and reliable platform for storing bulk data, it is equally notorious as a source of frequent security breaches.  As such special care must be taken in implementing an Oracle backup plan for production infrastructure.  S3 buckets should be carefully checked to ensure only authorized users can access backup data, no public access is allowed at all, and all data is properly encrypted.  In addition, House of Brick typically recommends implementing an immutable bucket pattern for long-term retention of key backups.

CONCLUSION

There’s obviously a lot more detail to each of these slices of the pie, but I’m hopeful that this overview has at least informed DBAs unfamiliar with running Oracle in AWS to all of the aspects that should be considered to properly secure an EC2 or RDS instance.