2024-01-04 Meeting notes

Craig McNally 

Axel Dörrer 

Chris Rutledge 

Jakub Skoczen 

Skott Klebe 

• MODGQL-175: John Coburn will open a PR to bump babel to version 7

From slack conversation, I think I've gathered the following:

• In this case (bank account and transit numbers), the information is highly sensitive.  
• Highly sensitive information should:
  • Be stored in it's own table
  • Accessed via a dedicated API
  • Protected by a dedicated permission
  • Encrypted in the database, not only on disk.  
    • This could mean either:
      • Explicitly encrypting/decrypting in the application layer and storing the encrypted data in postgres
      • Utilizing postgres extensions/modules to encypt certain columns, e.g. via pgcrypto (see https://www.postgresql.org/docs/current/encryption-options.html)

Let's review and discuss before providing this feedback to Raman.

Axel Dörrer also suggested that defining classes of sensitivity could help teams determine which techniques are applicable in various situations.  I agree having some general guidelines on this would be helpful.

• regular data
• low sensitive - permission based on same API
• high sensitive - permission based on dedicated API

It would probably help to provide concrete examples of data in each class.  This can be a longer term effort, we don't need to sort out all the details today.