InfoSphere Guardium and the Amazon cloud, Part 1
Explore Amazon RDS database instances and vulnerabilities
This content is part # of # in the series: InfoSphere Guardium and the Amazon cloud, Part 1
This content is part of the series:InfoSphere Guardium and the Amazon cloud, Part 1
Stay tuned for additional content in this series.
Amazon Web Services (AWS) is a collection of remote computing services that comprise the Amazon cloud computing platform. Two of these services are:
- Amazon Simple Storage Service (S3), which is an online file storage web service that provides storage through web services interfaces (REST, SOAP).
- Amazon Relational Database Service (RDS), which is a scalable distributed relational database web service. With Amazon RDS you can create and use your own database instances in the cloud and build your own applications around them.
In this article, get the information you need to leverage the IBM InfoSphere Guardium platform to assess your database security and harden your databases in the Amazon cloud. Learn how to:
- Use Guardium to work with Amazon RDS to discover database instances in the Amazon cloud.
- Access those instances within Guardium using datasources.
- Launch vulnerability assessments on those database instances in the Amazon cloud.
Cloud computing is computing that is distributed over a network such as the Internet. The cloud is the collection of distributed computing resources and networks. Cloud computing is becoming more popular and pervasive. As more workflows and data are moving into the cloud, so is InfoSphere Guardium. Cloud computing requires at least the same data security and protection as any other computing resources and data stores. Given the pervasive nature of the Internet, though, data security and protection are even more important in the cloud.
Platforms for cloud computing are offered by various vendors. Amazon provides popular commercially available cloud offerings. Amazon's cloud offering, called Amazon Web Services (AWS), includes a wide selection of computing services spanning the gamut from data storage to computing power, to databases, to analytics, to application deployment, to various applications themselves.
InfoSphere Guardium is an enterprise information database audit and protection solution that helps enterprises protect and audit information across a diverse set of relational and non-relational data sources.
Guardium can protect and monitor varied sources of data including:
- Large scale data warehouses such as Netezza, GreenplumDB, and Teradata.
- Hadoop distributions such as Big Insights, Cloudera, and HortonWorks.
- NoSQL databases such as CouchDB, MongoDB, and Cassandra.
- DB2, IMS, and VSAM for IBM System z.
- Other diverse types of data stores and protocols such as Microsoft Sharepoint, CIFS, HTTP, and FTP.
Of course, all of the traditional and popular relational database servers (RDBMS) are also supported:
- Oracle's Oracle Database and MySQL
- Microsoft's SQL Server
- Open source PostgreSQL
- IBM's database products DB2 and Informix
Datasources in InfoSphere Guardium
In Guardium, a datasource represents any potential source of data, a specific database, a file, or any other source of data. For many Guardium applications, the source of data is a database instance. InfoSphere Guardium supports the life cycle of data security protection, from discovery of sensitive data, to monitoring and auditing, to assessing security and hardening databases. Each type of datasource supports a subset of InfoSphere Guardium's features. When a datasource is created, it is first associated with a Guardium application that indicates what that datasource will be used for.
There are several applications defined in InfoSphere Guardium that use datasources: auditing, security assessments, change auditing, classification, custom domains, database analysis, value monitoring, replay, and others. After a datasource has been defined for Guardium, Guardium knows how to access that database by the specific application for which the datasource was defined.
You can define different parameters for datasource access, including:
- User name
- Service name
- Database name
- Connection properties
- File system directory
- Various database-specific details
In some cases, the database type is not actually a name at all. The database type might indicate a protocol such as HTTP or FTP, or even a single file, all of which Guardium can connect to and run Guardium security applications. Different Guardium applications require different types of database access. Typically, you would provide to Guardium the minimum privileges required by the applications that use the datasource, which can include login information for some Guardium applications. Guardium's vulnerability assessment, for instance, requires a high level of administrative access to the database so you would provide a user name and password to the database that has the required level of access.
Datasources in the cloud
Other than its location, there is little difference between a datasource that resides with a given enterprise and a datasource that exists within the cloud. Any given Guardium security feature can work equally well on datasources located in Amazon AWS (all other things being equal). And, because the cloud is reachable and usable by everyone, Guardium can provide software and services tailored to Amazon AWS for any customer that uses datasources on Amazon AWS.
Amazon AWS provides the Amazon RDS that allow users to quickly and easily create and use several different database instances. Currently, the supported database types are Oracle, MySQL, Microsoft SQL Server, and PostgreSQL. Guardium provides the ability to discover the instances in Amazon RDS and allows you to quickly and easily define datasources for each discovered datasource. With Guardium you can quickly and easily configure Amazon RDS to make those datasources accessible to Guardium's applications. Guardium makes it easy to quickly launch vulnerability assessments on those datasources. This collection of features in Guardium that facilitates security of Amazon RDS is called Amazon RDS Discovery.
Getting started with RDS Discovery
You access the RDS Discovery in the Guardium GUI. The Guardium GUI is accessible from an Internet browser. Point the browser to port 8443 at the host name or IP address of the Guardium appliance using the HTTPS protocol (https://hostname:8443). Log on to the Guardium GUI using your Guardium access credentials provided by your Guardium access manager. If you logged in with the admin user id, you can navigate to the Amazon RDS Discovery page by clicking the Tools tab, as in Figure 1.
Figure 1. Amazon RDS Discovery
Initially the page will display two text boxes, where you enter an Access Key and Secret Access Key, and a grid of Amazon regions.
The Amazon SDK used by Guardium requires the user to provide a secret key to allow Guardium access. To get your secret key, go to your AWS Security Credentials web page (in the upper right menu after you've logged into aws.amazon.com). From the Security Credentials page you can access keys, retrieve the key id for a previously created key, or create new keys. The secret keys are intended for applications such as Guardium to access your Amazon AWS account at your request.
Guardium does not save your key information in its own data store, send the key elsewhere, nor use the key for any other purpose. The key is saved temporarily, for convenience, on the Guardium system during your login session. If you leave and return to the RDS Discovery page the key fields will be filled in automatically for you. However, that information is discarded when you are logged out.
All communication from the Guardium server to Amazon AWS occurs through an encrypted HTTPS connection.
Amazon cloud computing resources are housed in data center facilities in different areas of the world. Each data center location, called a region, represents a separate geographic area. Each region contains multiple distinct locations called Availability Zones (AZs). AWS users can place resources, such as instances and data, in multiple regions. Resources aren't replicated across regions unless you specifically do so yourself. Each region is completely independent, and the services provided may differ to some degree across regions, though Amazon RDS is currently available in all regions. Any Amazon RDS activity you initiate runs only in a single region.
The list of regions, shown in Table 1, is generated dynamically by querying Amazon. If, for example, the table of regions fails to appear, it might mean that your Guardium appliance does not have access to the Internet. To access Amazon AWS, you must provide the appliance with access to the Amazon cloud over the Internet (otherwise Guardium won't be able to access your RDS instances).
Table 1. Amazon regions
|US East (Northern Virginia)||us-east-1||2006|
|US West (Northern California)||us-west-1||2009|
|US West (Oregon)||us-west-2||2011|
|AWS GovCloud (US)||us-gov-west-1||2011|
|South America (Sao Paulo, Brazil)||sa-east-1||2011|
|Asia Pacific (Singapore)||ap-southeast-1||2010|
|Asia Pacific (Tokyo)||ap-northeast-1||2011|
|Asia Pacific (Sydney)||ap-southeast-2||2012|
|China (Beijing)||Coming Soon|
Guardium's RDS Discovery allows you to discover RDS instances in any number of Amazon's regions simultaneously. Select whatever regions you wish to query for your RDS instances.
After you've entered your secret key id and secret key and selected one or more regions to query, you can click Discover to retrieve information about your RDS database instances in those regions.
A grid of discovered instances will appear below the list of regions, as in Figure 2.
Figure 2. Discovered instances
To produce the grid, the Guardium GUI server will simultaneously contact all the regions you selected to query Amazon about the instances that you created, as in Figure 3.
Figure 3. Contacting AWS regions
The column labeled Accessible in Figure 2 will show either a green check mark or a red X indicating whether Guardium will be able to connect to the instance. An RDS instance is considered accessible if it is public and it has "available" status. Possible status values are:
For each database instance, its current status and whether it is public are displayed in the Details column of the discovered instances, as in Figure 4. You will not be able to create a Guardium security group or a datasource for an inaccessible instance because those selections will be disabled.
Other details for each instance will be displayed, such as the database name, host and port, region it was found in, and whether it has an associated virtual private cloud (VPC) in Amazon.
You can use the grid in Figure 4 to create Amazon security groups and Guardium datasources, and launch vulnerability assessments on selected RDS instances in the grid. You can do all of this without leaving the RDS Discovery page.
Figure 4. Discovery grid selections
The final four columns, shown in Figure 5, indicate details about Guardium security groups and Guardium datasources that were previously created for those database instances. The first time you view a database instance in the grid there will be red Xs in the Security Group and Datasource columns. Use the Refresh button, which will appear in the upper right of the page, to display the latest data if any of the instances, security groups, or datasources have been changed elsewhere. All of these items can be changed simultaneously in other ways and by other users by accessing the Amazon Web Console, by using the Guardium GUI in a separate browser, or by using the Guardium CLI.
The Refresh button is also useful if you wish to redisplay the grid to fit the browser window if you've resized the browser window.
The filter box, shown above the Instances in Figure 1, is for ease-of-use. Enter text in the box to filter the table and show only the rows matching the filter text.
Whenever an operation is performed, whether it is the discovery operation or an operation on one or more of the database instances, errors can occur. If there are any resulting errors the Errors... button will become visible in the lower right of the page, as in Figure 5. The Errors... button will become visible or invisible with each operation that you perform, and it will show only the errors that were produced by the previous operation.
Figure 5. Errors button
Some errors might originate at Amazon AWS or be produced by Amazon's own code. Such errors will not be translated; they will appear exactly as they were received from Amazon. The window will also show you the region that produced the error.
For example, a common error occurs when the user incorrectly enters the secret key or secret key id. When this happens, each region will refuse to accept Guardium's request as the Guardium server contacts each region. Figure 6 shows an example error message for invalid credentials.
Figure 6. Invalid credentials error
Table 2 summarizes a few common errors and provides troubleshooting tips to resolve the issues.
Table 2. Troubleshooting common issues
|Government region is inaccessible||AWS government region is not accessible. Most customers will not be able to use the government region. Only select the regions in which you have RDS instances. The error message that appears will be the same error message as when you have entered an incorrect key or key id.||Do not select the region named "us-gov-west-1" in the region grid.|
|Invalid credentials||The secret key or key id you entered is incorrect.||Reenter your secret key id and secret key. To avoid typos, try using the copy and paste functions in the browser or use the Control-C and Control-V shortcuts to copy and paste text that you selected.|
|Invalid time or date, Signature not yet current||AWS will reject access if the date or time on the Guardium appliance that is connecting to AWS is incorrect by more than 15 minutes. (This does take time zones and daylight savings time into account.) The appliance must have the correct local time.||Set the Time Zone, Date and Time to the correct local settings|
Amazon security groups
Security groups permit access to Amazon RDS DB instances from the Internet. They are like simple firewalls, as shown in Figure 7. Access is granted by a list of classless inter-domain routing (CIDR) IP address ranges. Like all other Amazon AWS services, security groups are organized by region. There can be many security groups in each region and many CIDR IP address ranges in each security group.
Figure 7. Security groups control access
Each CIDR IP range describes an address and mask: ip1.ip2.ip3.ip4/mask. The mask works on the leftmost bits. Each database can be associated with multiple security groups. If any one of the CIDR IP ranges in any one of those groups grants access to a given IP address, then the database can be accessed from that IP. Table 3 shows sample CIDR IP ranges.
Table 3. Sample CIDR IP ranges
|0.0.0.0/0||The mask of 0 matches 0 bits in an address, thus allowing access from everywhere|
|192.168.12.0/23||The 23 bit mask is 255.255.254.0, so this represents the range 192.168.12.0 to 192.168.13.255|
|184.108.40.206/32||The mask of 32 bits matches all bits in an address, so this CIDR IP matches just the one address 220.127.116.11|
An Amazon security group has no relation to a Guardium group or the Guardium group builder. Amazon security groups are an Amazon construct only and Guardium does not maintain any record of them. Guardium provides simple functions to create a security group specifically for Guardium access and to add additional CIDR IP ranges to that group. However, it is up to each customer to decide just how to configure their security groups. The Guardium functionality is added for convenience but is not necessarily required.
A user might have a single group already created for their entire organization. Or, they might have no groups of their own and need to create one to allow access from the Guardium appliance. Users can create a group for Guardium either through the button provided or by accessing the Amazon AWS Web Console.
Regardless of how the security groups are created and configured, for Guardium to connect to an RDS instance the Guardium appliance must be granted access by at least one CIDR IP range listed in at least one security group attached to that RDS instance.
There are two types of security groups that apply to RDS instances: VPC or RDS. Some RDS accounts in some regions create all RDS instances in a default VPC.
RDS DB instances inside a VPC use VPC security groups. RDS DB instances not inside a VPC use RDS security groups. When an RDS instance is inside a VPC, there is a single place in AWS to define and manage network access rules for all AWS computing resources in the VPC, including DB instances. Use the EC2 console to manage VPC security groups. Use the RDS console to manage RDS security groups.
Your RDS console can tell you if you have a default VPC, which means you will be using VPC security groups rather than RDS security groups.
The Security Group button is enabled when instances are selected, as in Figure 8. Selecting the button will do three things:
- Create a Guardium Security Group (if it does not exist).
- Add the IP address of the Guardium appliance as seen by Amazon (if not in there already).
- Add the selected database instances to the group (if not associated already).
Figure 8 shows an example.
Figure 8. Created security groups
After the groups have been created you will see the names of the groups in the Guardium Security Group column of the instances grid. Instances in the same region will share the same security group. The list of CIDR IP addresses follows the name of the security group. As with a given instance, it may take some time for Amazon to create the group. You might see the status "adding" in brackets indicating that the groups are not yet ready for use. Eventually the status will become "active."
A red X will appear in the Guardium Security Group column if the Guardium security group has not been created, if the IP address associated with the instance is not in the group, or if the group has not been added to the instance's list of security groups. This does not necessarily mean that the instance is inaccessible. There might be a different security group attached to the instance that grants access to a range of IP addresses that includes the Guardium appliance. There may be a security group that grants access to the IP address of the Guardium appliance but that group was created by some other means and has a different name.
Security group configuration can be unique for each organization. Some might have a security group for their whole organization. Some may need to use the GUI to create a Guardium security group that provides access. It is up to the customer to choose how to provide RDS instance access.
Adding the IP address of the Guardium appliance, as seen by Amazon, to a security group for the instance should grant access to the RDS instance. Sometimes the network configuration of the Guardium appliance may interfere. For such cases, the user can manually add a CIDR IP address range to the Guardium security group by selecting the Add IP Range button.
Should there be connection issues, you can test access using the CIDR IP range 0.0.0.0/0, which will grant access to all and allow you to determine if the connection issues are with the security group configuration or something else. However, do not use that CIDR IP range for any live database with sensitive information. For increased security you should minimize permitted access.
If you want to remove the Guardium security group from a given DB instance or want to remove CIDR IP ranges from the Guardium security group, you need to use the AWS console.
Creating a datasource
For Guardium to be able to work with an RDS instance you must create a datasource for it. In RDS Discovery, for each instance for which you want to have an associated datasource you enter a user and password that will be used to connect to the instance. For the user you can choose either the master user that was created when the RDS instance was first created or select any other user that has since been created for that database instance. After that, you will be able to create their datasources by selecting those rows in the grid and clicking Create/Update Datasources.
After the operation is complete you'll see the datasource names in the datasource column. The datasource will be stored in Guardium's data store and will be shown in the grid at any point in the future when you discover the same RDS instance. Should you wish to change the user or password for an instance, you can repeat the operation.
If you have any specialized configurations for the datasource, or want to test whether Guardium can successfully connect to the datasource, you can select a single row with a datasource created and click Datasource Definition.... Once selected, you will see the standard datasource definition form that is accessible from Guardium's Datasource Definitions builder. All the datasource details will be shown, as in Figure 9.
Figure 9. Datasource Definition
By using the datasource definition form you can make any modifications to the datasource, such as any connection properties or the description. However, most properties should not be changed because they match the settings on Amazon. The name of the datasource is derived from the instance host name, port, and region, which together are unique for each of your RDS instances.
A useful feature on this page is the Test Connection button, which lets you verify that you can successfully connect before you try to use the datasource. figure 10 shows a successful connection. If you cannot connect, there are many possible reasons.
Figure 10. Successful connection
If the connection times out it may in fact be that the security groups are not configured to allow access to the IP address of your Guardium appliance. To verify your security groups:
- Check all the security groups using the AWS console.
- Verify the Guardium appliance IP address with your system administrator.
- Try connecting to a test DB instance with a security group that has the CIDR IP range 0.0.0.0/0, which grants access to all.
- Try connecting to the DB instance using other tools. For example, use the MySQL client to connect to a MySQL database or use the SQL*Plus tool to connect to an Oracle database. Use a generic database tool like Razor SQL to connect to any number of different database types.
If your security groups are configured correctly then there are other reasons why a connection may fail, such as:
- An incorrect user id or password. Typically there will be an error that indicates this in the dialog that appears.
- The instance is not available at that moment. Check the status of the instance in the Guardium instances grid or the AWS console. The instance will not be accessible if it is being backed-up, deleted, modified, rebooted, if the master credentials are being changed, or if the instance has failed for some reason.
If the connection test passes, then you know that you can successfully connect to the RDS databases instance when running a vulnerability assessment.
Other datasource views
Datasources created by Amazon RDS Discovery are created for the security assessment application. They can be shared with other Guardium applications, which you can do by navigating to the Datasource builder and checking the box that indicates you want to share the datasource.
You have other traditional ways to view the datasources you've created. You can view them from the datasource builder, found in the Tools tab, as in Figure 11.
Figure 11. Datasource Builder
You can also see the datasources from the datasources report in the Daily Monitor tab, as in Figure 12.
Figure 12. Datasources Report
The Guardium Vulnerability and Threat Management solution is the first step in managing security and compliance for any database environment. Tests, along with a process workflow, help you identify and address database vulnerabilities in an automated fashion, thereby improving configurations and hardening infrastructures.
With the Guardium Vulnerability Assessment application organizations can identify and address database vulnerabilities in a consistent and automated fashion. Guardium's assessment process evaluates the health of your database environment and recommends improvements by:
- Assessing system configuration against best practices and finding vulnerabilities or potential threats to database resources, including configuration and behavioral risks.
- Finding any inherent vulnerabilities in the environment.
- Recommending and prioritizing an action plan based on discovered areas with the most critical risks and vulnerabilities. The reports and recommendations provide guidelines on how to meet compliance changes and elevate security of the evaluated database environment.
Vulnerability assessment of RDS instances
After you have a datasource for an instance, and you know the Guardium appliance has access to the instance with a security group, you can launch a vulnerability assessment on that instance. Figure 13 outlines the process.
Figure 13. Vulnerability assessment of RDS instances
After you select one or more accessible instances with associated datasources, the Launch Vulnerability Assessment button is enabled. The assessment will run several security tests against a number of database instances and create a report of the results. Click Launch Vulnerability Assessment to launch the assessment on the selected database instances, as in Figure 14.
Figure 14. Vulnerability Assessment dialog
You can enter the description of an existing vulnerability assessment or a new description. You can also enter the recipients of the assessment report. However, all of the fields in the dialog are optional. Click OK to launch the assessment. Another dialog will indicate if the assessment was successfully launched. An assessment is launched within an audit process, which is a process that runs in the background on the Guardium appliance. The audit process runs its associated tasks in succession, records the results, and delivers the results to one or more users.
If a vulnerability assessment with the given description does not already exist, then it will be created. If a new security assessment is created it will be created with the selected RDS instance datasources and all the available tests relevant to those database types, whether Oracle, MySQL, SQL Server, or PostgreSQL.
If the security assessment already exists, then the selected RDS instance datasources will be added to the assessment (if not already there). If the existing assessment has no tests at all, then all available tests relevant to the database types will be added. Otherwise, the tests will remain unchanged.
An audit process will be created for the vulnerability assessment unless one already exists. It will have the same description as the assessment and will contain just one task: the security assessment. The process will be submitted for execution immediately, although it may take some time for the process to complete.
After the assessment is complete, the result is distributed to all receivers.
Audit process views
After the audit process has been launched, in the GUI you can view the status in the Guardium Job Queue and the Audit Process Log. Both of these reports are available from the Guardium Monitor tab in the GUI.
You can also access the results manually from the Audit Process Builder, as shown in Figure 15.
Figure 15. Audit Process Builder
The audit process results include the results of the individual tests run against the database instances. A tabular graph summarizes all the tests that were executed within the assessment. An extensive results section provides:
- A detailed description of the tests that were executed.
- Information about the target RDS instance.
- The pass and fail status of each test, severity information, and the reasons for that status.
- Information about the tests themselves and external references regarding the origins of the tests.
More information about vulnerability assessments
This article contains only a summary of vulnerability assessments. There is a wealth of security information in vulnerability assessments, but the details are beyond the scope of this article. Related topics has more information about InfoSphere Guardium Vulnerability Assessments.
Organizations are moving into the cloud to reduce the costs of storing data and maintaining their own information technology infrastructure. A move to the cloud introduces new challenges in data security. Guardium is already well-suited for private and hybrid cloud environments. Guardium's capability to easily discover, assess, and harden Amazon RDS instances can help you protect data in the public cloud. The cloud-related benefits are also in sync with Guardium's mission to provide a consistent and enterprise-wide solution for security, data protection, and auditing.
Stay tuned for Part 2 of this series, which will discuss how Guardium uses Amazon S3 for backup and restore operations.
- Learn more about InfoSphere Guardium Data Security.
- Get details about Assessing Vulnerabilities with the InfoSphere Guardium Vulnerability Assessment Solution.
- Read the Assess and Harden Help Book for information on Vulnerability Assessments.
- The InfoSphere Guardium Information Center has product overviews, what's new, documentation, and related resources.
- Watch videos on the InfoSphere Guardium YouTube channel, including videos of what's new in version 9.1.
- Watch a YouTube video about Amazon RDS.
- Read the AWS documentation for information about AWS services.
- Amazon web services has more about using Amazon RDS.
- Configure your AWS resources by visiting your EC2 or RDS console.
- Follow InfoSphere Guardium on Twitter.
- InfoSphere Guardium's Vulnerability Assessment.
- Evaluate IBM products in the way that suits you best.