2023-12-14 Meeting notes

@Craig McNally 

Dec 25, 2023 → Jan 1, 2024 

@Julian Ladisch 

Dec 25, 2023 → Jan 1, 2024 

@Axel Dörrer 

@Ryan Berger 

Dec 25, 2023 → Jan 1, 2024 

@Chris Rutledge 

Dec 18, 2023 → Jan 1, 2024 

@Jakub Skoczen 

@John Coburn 

Dec 22, 2023 → Jan 1, 2024 

@Skott Klebe 

5 min

Planned Vacation

Team

Unless @Axel Dörrer or @Jakub Skoczen want to run the meeting, we will cancel Dec 28, 2023 

?

Anything Urgent? Review the Kanban board?

Team

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: