Security and Team Management in Crunchy Bridge

I wanted to take a little time today to walk through some of the security and team controls you get out of the box on Crunchy Bridge. Within teams for Crunchy Bridge you have the ability to:

• Restrict authentication for a team to SSO
• Event logs of all actions for a team
• Audit logs of queries run against your database

We'll take a look at each of these in deeper detail. First, if you're unfamiliar with teams in Crunchy Bridge, they are the basic building blocks for collaborating. Teams allow you to share the ability to provision/scale/deprovision resources, to configure and manage your PostgreSQL clusters, and to grant access to your databases to others within your project.

Teams are intended to be low friction and you can create them in flexible ways to suit your needs. If you're a very small startup with just 3-4 engineers 1 team shared among the entire team may make sense. Are you a large engineering org with 1,000s of engineers and different business units? You may find that each business unit has not one team, but multiple teams separating prod, staging, and dev environments.

Team event log

Knowing who provisioned a cluster, who changed your logging config, or even who accessed credentials is standard operating fare when running a system. Within Crunchy Bridge all this auditing is enabled by default and accessible to administrators of your team. Your audit events are available on a per cluster or a per team level. You can view them within the Crunchy Bridge Console by navigating to the settings. If you want to retain them locally they’re fully available in our API as well.

Teams, Users, and Auditing

Auditing your Crunchy Bridge account is one step of the puzzle, but how do you monitor and track for bad actors within the system? Keeping your database under lock and key is one option, but you slow down developer velocity.

By default we create several types of users for you on your database. On many of these users we have full auditing enabled to help you from a security and compliance perspective. This auditing is done via PGAudit, this means every command run by that database user is logged alongside your Postgres logs. This is great for security, but you probably don't want to log every query from your application. For this reason we recommend you connect with your "application" user for standard usage.

• Do you want full Postgres super user (for creating extensions, other users, changing Postgres configs)? Connect with the postgres superuser.
• Want to simply connect your application for standard table creation and inserting/updating/deleting data? Use the application user
• Want to grant read-only access to others in your team? Add them as a member within the team. They'll have read-only access by default, but not be able to scale up/down resources and no super user access.
• By default all members have auditing on their users enabled. Want more control of that or to disable? Visit the role settings for your cluster.

With auditing enabled for the user roles via pgaudit, you’ll automatically see queries run from those users in your logs:

Enforcing SSO for your team

Data is a precious asset and ensuring your team follows good account practices makes sense. SSO makes it easy to off board your users, enforce 2FA, and much more. Most companies support SSO at some point in their journey and allow you to restrict a teams access to being via SSO. On Crunchy Bridge it's not part of an enterprise or business tier, it's there for everyone. No need to pay more for better security, simply be logged in as an admin of your team with SSO, toggle it and it will be required for all future users.

Data isolation by default

With the above you have tools you need to help with managing your own users, audit logs, and security. The other side of that coin is commonly “What does Crunchy Data do to keep my data safe?” We may do a follow-on deep dive in this area, but to quickly give you an overview:

• Encryption at rest - All data within Crunchy Bridge is automatically encrypted at rest
• Encryption in transit - All data in transit is encrypted with TLS 1.2 and up
• Certificate verification - You can use the certificate within your team to verify the PostgreSQL server you’re connecting to. And if you use our CLI this is automatically done for you without you having to take any extra steps.
• Network isolation - By default all Postgres clusters are in isolated VPCs. We have full support for VPC peering, or you can self-service manage your firewall rules.
• Continuous protection - We capture daily Postgres base backups and replicate your write-ahead-log (WAL) every 16 MB or 60 seconds whichever comes first. This powers our ability to recover your database to any point in the last 10 days should you need to. You have backups and disaster recovery included without every having to do anything.

Hopefully this has given a good view into both the flexibility you have out of the box, as well as security and tracking to help keep your data safe.