We just released console1984 and audits1984. The first gem extends Rails consoles to make them auditable and to protect sensitive accesses. The second one is a simple auditing tool. This constitutes the other essential part of the technology we developed at Basecamp to raise the privacy bar in Rails applications, and I am thrilled to finally open source it.
Console1984
console1984 is an IRB-based Rails console extension that does three things:
Console1984
console1984 is an IRB-based Rails console extension that does three things:
- Record console sessions with their user, reason and commands.
- Protect encrypted data by showing the ciphertexts when you visualize it.
- Protect access to external systems that contain sensitive information (such as Redis or Elasticsearch)
Audits1984
audits1984 is a Rails engine that provides a simple auditing tool for sessions recorded by console1984.
Development
We created the first version of console1984 in May of 2020, in parallel to work on Active Record encryption. Initially, it focused on protecting encrypted database information, and later we added support for protecting external systems like Elasticsearch and Redis.
We created the first version of console1984 in May of 2020, in parallel to work on Active Record encryption. Initially, it focused on protecting encrypted database information, and later we added support for protecting external systems like Elasticsearch and Redis.
For a long time, we used a very rudimentary system to audit the console sessions. We used rails-structured-logging (another gem we intend to release) to emit JSON trails of the commands executed, we ingested those via our logging pipeline and examined them with a Kibana dashboard. Finally, we exported the Kibana console sessions to a Numbers spreadsheet where we registered our audits. This did the job, but it was slow and cumbersome to use.
We created an auditing team in Basecamp in charge of performing these console audits periodically and posting a report for the rest of the company. These reports include a summary of what triggered sensitive accesses, and they have been helpful to detect the need for tools that removed console usages in everyday scenarios. As a general rule, any console-sensitive access has to contain explicit consent by the customer. The only exceptions are incidents where we need to run code with decrypted access in a console.
Since we intend to use console1984 in other apps (like Basecamp 4), some tool we could reuse across apps made a lot of sense, so we created audits1984. It's the kind of project where you can get derailed adding features, so I decided to allocate one week of development to get the initial version working. This was immensely helpful to clarify scope and decisions. As part of creating this tool, we replaced the system to record audit trails to use the database instead of structured logs.
Give it a try!
A feeling shared by many at Basecamp is that once you get used to protected consoles and encryption, going back to unprotected ones feels wrong. For most of the work you do on production consoles, you don't need to see customers' personal information. Not on purpose, of course, but not by accident either.
Also, console1984 makes a great case to use Active Record encryption. It shows why it's useful to formally capture sensitive information at the code level: you can build protection mechanisms around it! console1984 or automatic params filtering are examples of that.
Update 2021-12-22: Check the last part of the puzzle: mass_encryption, a library to encrypt data in bulk.
Update 2021-12-22: Check the last part of the puzzle: mass_encryption, a library to encrypt data in bulk.