Date

11 Jan 2024

Attendees

Name	Present	Planned Absences
Craig McNally	Y
Julian Ladisch	Y
Axel Dörrer
Ryan Berger
Chris Rutledge	Y
Jakub Skoczen
John Coburn	Y
Skott Klebe

Discussion items

Time

Item

Who

Notes

30 min

Anything Urgent? Review the Kanban board?

Team

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

Time permitting

Advice for handling of sensitive banking information

Team

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.

Next Steps:
- Clearly define/formalize the various classes
  - Come up with concrete examples of each class
- Build out guidance
  - Come up with concrete examples of how to protect each class of data.
- Consider storing some classes of data outside of postgres altogether - e.g. in secret storage.
  - What would be the guidance we provide to teams for this so we don't end up with each team doing things differently?
  - SecretStore interface and existing implementations are currently only read-only. They would need to be extended to allow for creation/mgmt of this information.
- Craig to start a conversation in slack about this.
  - Seeking a volunteer to generate a draft document for us to review at a later meeting.

Today:

Action items

Browser not supported