Page Comparison

• We need to determine if DevOps can work on 

  Jira Legacy
  server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-3896

   or if they don't have bandwidth, and the debian packages aren't used anymore, archive them.  It sounds like some SysOps do use this, but we know that DevOps has very little bandwidth these days.
  • Action:  Craig to ask in #devops if they can and are willing to work on this, then we can decide next steps.
  • Update:  Craig Posted, in #devops, but not a single reply
  • This is referenced in the single-server deployment documentation, and not part of the official flower releases
  • Maybe the core platform team can take on this work since there hasn't been any replies from the devops community.
  • Action:  Reach out to Jakub Skoczen to see if we can get some movement on this from either devops or core-platform teams (Craig)
  • Action:  Ask #sys-ops if this is still needed, or can they switch to the docker containers. (Craig)
• Another prisma scan was done against the Q release candidate versions of modules.  Several issues were found and logged.
  • Some of these are related to the Architectural changes being proposed by the Eureka team.  Craig McNally will triage these with the team.
• Discussed potential improvements to Jira workflows (SECURITY project)
  • Automatically embargo (set the security level to Folio Security Team)
  • Allow the creator to see issues after being embargoed

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.

Axel Dörrer 

Due to some absences on different reasons the group stalled. Axel will try to reactivate the group.