Logo: Fujitsu and home icon
    Download trial version
    Fujitsu Logo

      Protecting clients' data has long been an immediate concern of mine as it probably is for you. Which is why I'm excited by Data Masking.

      When last we spoke, I shared my experiences (and frustrations) as a young developer of e-commerce stores for big names in the music industry and the odd charity. We’re going back 15 years mind you. I told you how amazing it was to discover PostgreSQL for the first time – its speed and stability.

      But I also mentioned my ongoing anxiety in regards to security of my clients’ data; anxiety that would bother me for 15 years.

      Little did I know then that in the not-too-distant future, Fujitsu would develop several features, as part of FUJITSU Enterprise Postgres, which would allow me to sleep more easily at night. Encrypted Tablespaces was one of those features. Data Masking (also frequently referred to as Data Redaction) is the other.

      Data Masking is more interesting than Encrypted Tablespaces in many ways. You can define different levels of security for accessing different pieces of data. As an example, let’s say you run a decent-sized company and have hired call-centre staff who will need to access some customer details but not others. Perhaps they need to access the customer name and address, but not the phone number. You can obviously do this within a web application. The application could simply replace some details with XXX, e.g. telephone number +61 022 22222 would be displayed as +61 xxx xxxx to the user.

      This might work well, but you would be much better off restricting this information at the database level on the server (before that data goes over your network – after all, it’s pretty easy to sniff the network traffic), so that if you have more than one application, you don’t have to make changes to them all. Data masking in postgresql

      With a Data Masking feature you can simply add a rule stating that if the person accessing the database is in a particular group of users, then the data coming from the phone number field is replaced with XXX, or --- (basically, you can use whatever you fancy).

      You can even get it to hand you random data that looks valid to your application. In the telephone number example, the database could return +61 123 2345, or maybe +61 334 4521, not correct but valid looking to your app. Done and dusted. The application development team and the call centre staff can try all they like, but they won’t be able to get at the raw data without having a different login to the database.

      You can imagine how useful this is, particularly if your company is big enough to need to securely store car number plates, dates of birth, medicare numbers, security answers or credit card details etc. Although, if you feel you need to store card data (PAN and Expiry Date in card payment industry terms), then I would very strongly advise that you take a look at using a tokenisation service from your Payment Services Provider and store the token instead.

      Data Masking and Encrypted Tablespaces are just two of the security-enhancing features on FUJITSU Enterprise Postgres that would have made my life so much easier had they existed 15 years ago. It just goes to show how PostgreSQL, which was amazing when I first encountered it, will only get better in the future.

      If you are interested in learning more about Data Masking and how it may improve your PostgreSQL database, please contact us directly. Fujitsu provides 24/7 Australian-based PostgreSQL support and services, DBA and developer training, and our own enhanced version of PostgreSQL - FUJITSU Enterprise Postgres.

      Data masking white paper


      Topics: Data Masking, Data Redaction

      Receive our blog

      Receive notification of PostgreSQL-based articles for business and technical audiences.

      Search by topic

      see all >

      Read our latest blogs

      Read our most recent articles regarding all aspects of PostgreSQL and FUJITSU Enterprise Postgres.