DataSunrise Achieves AWS DevOps Competency Status in AWS DevSecOps and Monitoring, Logging, Performance

Dynamic Data Masking for Amazon Aurora

Dynamic Data Masking for Amazon Aurora

Introduction

As businesses increasingly rely on cloud databases like Amazon Aurora, the need for robust security measures grows. One powerful tool in the data protection arsenal is dynamic data masking. Did you know that 68% of data breaches involve non-malicious human action? This alarming statistic highlights the importance of implementing strong data protection strategies, including dynamic data masking for Amazon Aurora.

What is Dynamic Data Masking?

Dynamic data masking is a security feature that hides sensitive data in real-time as it’s being accessed. Instead of altering the original data, it applies masks or transformations on-the-fly when users query the database. This approach ensures that only authorized users see the full, unmasked data, while others receive masked versions.

Key benefits of dynamic data masking include:

  1. Enhanced data privacy
  2. Reduced risk of data breaches
  3. Simplified compliance with data protection regulations
  4. Flexibility in managing data access

Amazon Aurora’s Dynamic Data Masking Capabilities

Amazon Aurora, a powerful relational database engine, offers built-in dynamic data masking features. These capabilities allow you to protect sensitive data without modifying your application code.

Setting Up Dynamic Data Masking in Aurora

To implement dynamic data masking in Amazon Aurora PostgreSQL, we can leverage the database’s built-in Row-Level Security (RLS) feature. This approach offers a powerful and flexible way to control data access at a granular level. Let’s walk through the process, starting with creating some sample data and then implementing RLS policies to achieve dynamic masking effects.

-- Create the employees table
CREATE TABLE employees (
    employee_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    email VARCHAR(100),
    department VARCHAR(50),
    salary NUMERIC(10, 2)
);

-- Insert sample data
INSERT INTO employees (first_name, last_name, email, department, salary) VALUES
('John', 'Doe', 'john.doe@company.com', 'IT', 75000),
('Jane', 'Smith', 'jane.smith@company.com', 'HR', 65000),
('Bob', 'Johnson', 'bob.johnson@company.com', 'IT', 70000),
('Alice', 'Williams', 'alice.williams@company.com', 'Finance', 80000),
('Charlie', 'Brown', 'charlie.brown@company.com', 'HR', 60000);

Next, let’s set up the necessary users and roles to demonstrate how different access levels affect data visibility.

-- Create roles
CREATE ROLE it_manager;
CREATE ROLE hr_manager;
CREATE ROLE finance_manager;
CREATE ROLE employee;

-- Create users and assign roles
CREATE USER john_it WITH PASSWORD 'password123';
GRANT it_manager TO john_it;

CREATE USER jane_hr WITH PASSWORD 'password123';
GRANT hr_manager TO jane_hr;

CREATE USER alice_finance WITH PASSWORD 'password123';
GRANT finance_manager TO alice_finance;

CREATE USER bob_employee WITH PASSWORD 'password123';
GRANT employee TO bob_employee;

-- Grant necessary privileges
GRANT SELECT, INSERT, UPDATE, DELETE ON employees TO it_manager, hr_manager, finance_manager;
GRANT SELECT ON employees TO employee;
GRANT USAGE, SELECT ON SEQUENCE employees_employee_id_seq TO it_manager, hr_manager, finance_manager;

Let’s now implement Row-Level Security (RLS) to achieve our dynamic data masking goals.

-- Enable RLS on the employees table
ALTER TABLE employees ENABLE ROW LEVEL SECURITY;

-- Create RLS policies
CREATE POLICY employee_self_view ON employees
    FOR SELECT
    TO employee
    USING (email = current_user);

CREATE POLICY manager_department_view ON employees
    FOR ALL
    TO it_manager, hr_manager, finance_manager
    USING (
        CASE 
            WHEN current_user = 'john_it' THEN department = 'IT'
            WHEN current_user = 'jane_hr' THEN department = 'HR'
            WHEN current_user = 'alice_finance' THEN department = 'Finance'
        END
    );

-- Create a view for masked salary information
CREATE OR REPLACE VIEW masked_employees AS
SELECT 
    employee_id,
    first_name,
    last_name,
    email,
    department,
    CASE 
        WHEN pg_has_role(current_user, 'hr_manager', 'member') 
             OR pg_has_role(current_user, 'finance_manager', 'member') 
        THEN salary::text
        ELSE 'CONFIDENTIAL'
    END AS salary
FROM employees;

-- Grant access to the view
GRANT SELECT ON masked_employees TO it_manager, hr_manager, finance_manager, employee;

SELECT * FROM employees;

The last command is the select. All the SQL statements above are executed from postgres user. And since this is an admin he can see all the data in the employees table:

The HR and IT department users can only see their department employees:

And finally the salary is masked for john_it user in masked_employees view:

Implementing Dynamic Data Masking with DataSunrise

While Aurora’s native masking capabilities are useful, third-party tools like DataSunrise offer more advanced features and granular control over data masking.

Tracking Masking Events

To monitor the effectiveness of your masking rules, it’s crucial to track masking events. DataSunrise allows you to enable logging for masking events during rule setup

You can then view these logs in the DataSunrise dashboard or export them for further analysis.

Best Practices for Dynamic Data Masking

To get the most out of dynamic data masking for Amazon Aurora, consider these best practices:

  1. Identify sensitive data: Regularly audit your database to identify and classify sensitive information.
  2. Use appropriate masking methods: Choose masking techniques that balance security and usability.
  3. Test thoroughly: Ensure that masking rules don’t break application functionality.
  4. Monitor and adjust: Regularly review masking logs and adjust rules as needed.
  5. Combine with other security measures: Use data masking alongside encryption, access controls, and auditing.

Data-Driven Application Testing: Masked vs. Synthetic Data

When testing data-driven applications, two main approaches are available:

  1. Testing with masked data
  2. Testing with synthetic data

Masked Data Testing

This approach uses your actual production data but applies masking rules to protect sensitive information. Benefits include:

  • Realistic data scenarios
  • Easier to set up
  • Maintains data relationships

However, there’s still a small risk of data exposure, and masked data may not cover all possible test cases.

Synthetic Data Testing

This method uses artificially generated data that mimics the structure and characteristics of your production data. Advantages include:

  • Zero risk of exposing real data
  • Can generate edge cases for thorough testing
  • Avoids data privacy compliance issues

The downside is that creating realistic synthetic data can be challenging and time-consuming.

Conclusion

Dynamic data masking for Amazon Aurora is a powerful tool for protecting sensitive data in cloud environments. By implementing masking strategies, businesses can significantly reduce the risk of data breaches and simplify compliance with data protection regulations. Whether using Aurora’s native capabilities or advanced tools like DataSunrise, dynamic data masking should be a key component of your database security strategy.

Remember, effective data protection is an ongoing process. Regularly review and update your masking rules, monitor masking events, and stay informed about the latest security best practices to keep your sensitive data safe in the ever-evolving digital landscape.

DataSunrise offers user-friendly and cutting-edge tools for database security, including comprehensive audit capabilities and data discovery features. To learn more about how DataSunrise can enhance your database security and see our solutions in action, visit our website to schedule an online demo.

Next

Static Data Masking for Amazon Aurora

Static Data Masking for Amazon Aurora

Learn More

Need Our Support Team Help?

Our experts will be glad to answer your questions.

Countryx
United States
United Kingdom
France
Germany
Australia
Afghanistan
Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belgium
Belize
Benin
Bermuda
Bhutan
Bolivia
Bosnia and Herzegovina
Botswana
Bouvet
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Canada
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Congo, Republic of the
Congo, The Democratic Republic of the
Cook Islands
Costa Rica
Cote D'Ivoire
Croatia
Cuba
Cyprus
Czech Republic
Denmark
Djibouti
Dominica
Dominican Republic
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard Island and Mcdonald Islands
Holy See (Vatican City State)
Honduras
Hong Kong
Hungary
Iceland
India
Indonesia
Iran, Islamic Republic Of
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Japan
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Korea, Democratic People's Republic of
Korea, Republic of
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Libyan Arab Jamahiriya
Liechtenstein
Lithuania
Luxembourg
Macao
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States of
Moldova, Republic of
Monaco
Mongolia
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
North Macedonia, Republic of
Northern Mariana Islands
Norway
Oman
Pakistan
Palau
Palestinian Territory, Occupied
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Helena
Saint Kitts and Nevis
Saint Lucia
Saint Pierre and Miquelon
Saint Vincent and the Grenadines
Samoa
San Marino
Sao Tome and Principe
Saudi Arabia
Senegal
Serbia and Montenegro
Seychelles
Sierra Leone
Singapore
Slovakia
Slovenia
Solomon Islands
Somalia
South Africa
South Georgia and the South Sandwich Islands
Spain
Sri Lanka
Sudan
Suriname
Svalbard and Jan Mayen
Swaziland
Sweden
Switzerland
Syrian Arab Republic
Taiwan, Province of China
Tajikistan
Tanzania, United Republic of
Thailand
Timor-Leste
Togo
Tokelau
Tonga
Trinidad and Tobago
Tunisia
Turkey
Turkmenistan
Turks and Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Venezuela
Viet Nam
Virgin Islands, British
Virgin Islands, U.S.
Wallis and Futuna
Western Sahara
Yemen
Zambia
Zimbabwe
Choose a topicx
General Information
Sales
Customer Service and Technical Support
Partnership and Alliance Inquiries
General information:
info@datasunrise.com
Customer Service and Technical Support:
support.datasunrise.com
Partnership and Alliance Inquiries:
partner@datasunrise.com