Offline sync restrictions for sensitive vaults
I brought this up in the audit trail discussion, but I thought it appropriate to spin it off into a separate discussion since it identifies a distinct feature request. I would love to be able to create vaults that keep their data stored in the 1Password cloud rather than syncing to the users' devices automatically. In my mind, this would work similar to travel mode though the primary purpose would be to grant users access to credentials/secrets while retaining the ability to audit whether or not they ever actually took possession of them.
This is a killer feature from a compliance standpoint where we need to balance minimum necessary access with business continuity and disaster recovery needs -- a type of situation I deal with on a nearly daily basis with my clients. It's also a nice feature to have in place as a small business working with an MSP, e.g., my MSP needs access to domain administrator or AWS root credentials but only under a restricted set of very well-defined circumstances.
While there are cases where I can justify the deployment of separate secret management or privileged access management infrastructure to satisfy this sort of requirement, this isn't a workable option for many of my smaller and less technically sophisticated clients. Sync-restricted vaults would provide a low friction, low complexity solution that small teams can take into account within their processes.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
@cjcampbell: Hmm. Thanks for bringing this up! It's interesting to think about something like this similar to Travel Mode with a different use case. As it sounds like you're aware, we've got some ideas for auditing in general. But in this instance, would Travel Mode functionality be sufficient for your needs here, provided it was possible to decouple from that (so you could still use Travel Mode separately if you wanted)? I'm struggling with how to even describe this otherwise, so I'd love to hear more of your thoughts.
0 -
I think I understand what you’re saying, and I do think travel mode could be adapted to provide a good-enough solution for the near-term if there was a separate trigger. The solution may not be as refined as I’d like to see in the long term, but it’s workable given that we’d rotate passwords after access in most of the scenarios I’ve described.
Let’s say that there is a trigger for emergency mode at the account level. By default, accounts are in non-emergency mode (which is a parallel for travel mode on these sensitive vaults). In the event of a disaster, the switch can be thrown in order to sync the vault to the device.
Another approach would be to create a workflow where a vault can be provisioned to users in a disabled state. Authorized users can throw the switch to enable their own access to the vault (which can be audited and trigger appropriate notifications). This approach has a slight advantage in granularity over a singular all or nothing emergency mode switch, although I think it works a bit more like the recovery workflow than travel mode.
0 -
@cjcampbell: Oh! Thank you! That's perfect! Makes total sense, now that you lay it out like that. I'm still not sure what I'd call this:
Authorized users can throw the switch to enable their own access to the vault (which can be audited and trigger appropriate notifications).
But I can see how it would be useful in some scenarios to technically have access, but have a failsafe in place to prevent you from actually accessing it (after enabling and then downloading it?) on your device — sort of like breaking the glass for a fire alarm and extinguisher. It does sound like it would be useful to have that triggered separately from Travel Mode, even if the mechanism is similar. And then the admin will know you've triggered this, and that the vault should be treated as accessed (for example to change credentials afterward). Certainly something we can consider for the future. Thank you again! :)
0 -
“Break glass” is actually one of the most common ways of referring to this sort of setup and scenario, so I’d say you picked the perfect metaphor.
My pleasure to make the suggestion. AgileBits has a great product, and I’m happy to kick in my two cents if it means you can improve it even further!
0 -
@cjcampbell: Thanks for the compliments and the feedback. :chuffed: We always love to hear about different ways folks could see themselves using 1Password. Travel Mode itself grew out of a desire to better address a need customers had devised their own solution to, so y'all really are a great help in pointing us towards cool stuff we can do. :+1:
0 -
@cjcampbell : we've played around with such a concept before and got it as far as a working prototype where you could designate a vault as "online only". The contents of the vault would be downloaded to the app, but the encryption keys to decrypt the data were never saved so unless the app was online to request the keys from the server there was no way to access the data. It was a neat prototype, but it added a lot of complexity to an already-pretty complex process and we weren't quite happy with the overall approach.
There's definitely merit in the idea, and we hope that one day we'll have a complete solution for this.
In the mean time, in the Pro plan of 1Password Teams, there's an option to limit the availability of a vault to certain types of apps. So it's actually possible to make some vaults only accessible via the 1Password.com webapp, such that they're never downloaded/cached on our native apps. That might be worth considering as well as a short term solution.
Rick
0 -
@rickfillion Thank you for that info. If you ever need external feedback or testers for related functionality, I’d be happy to help.
Thanks as well for the interim option. I’d missed/forgotten about that capability. I imagine that means access would be audited since it occurs in the web app. If that’s the case, this will do for immediate needs.
0 -
@cjcampbell : this would depend on what you mean by audited. What specifically are you looking for there?
Rick
0 -
@rickfillion I was hoping that user access to that vault would appear in the security log (pro account) if it occurred through the web (and the vault was restricted to the web). I know that this wouldn't make much sense in the desktop/mobile app use case, but would add value in the web app. Did some preliminary testing and didn't see an entry in the log.
0 -
@cjcampbell : yeah... no audit events are recorded when a user goes into a vault.
We're working on a project to bring admins some useful information in that regard. Hopefully we can get that into beta soon.
Rick
0
