Administration tools

[marcua]

@sofiaritz pointed out that it would be helpful to provide administration tools for common administrative use cases. I agree, and am sorting some thoughts out here.

• What are an initial set of administrative needs?
  • Revoke a token due to some form of abuse
  • Disable an account (can accept a reason)
    • Sets the visibility of its databases to private and removes all collaborators
    • Revokes all tokens
  • Enable an account
  • Deleting an account (and all databases it owns via cascading deletes)
  • Change visibility of/disable a database (due to intellectual property infringement, etc.). Relies on us implementing option public visibility for public visibility of databases, access control, etc. If disabling, a reason must be set (random example from the GH DMCA repo: https://github.com/Wanjieming/IPTV).
• How will it be implemented
  • Is this ayb admin [revoke_token|disable_account|...], which you run on the primary server? (Pro: limits attack surface, Con: no exposed API)
  • Is this a new set of endpoints that are restricted to users with administrative privileges? (Pro: API allows us to build UI around it in the future, Con: increases attack surface of server)

[sofiaritz]

Re: initial set.

The things I have listed are the following:

• Revoking tokens from an user
• Revoking all tokens instance-wide
• Disabling an account
  • Sets the visibility of its databases to private and removes all collaborators
  • Revokes all tokens
  • A reason can be set
  • (Enabling a disabled account)
• Deleting an account
  • Deletes the databases associated with that account
• Change the visibility of a database
  • Add an option to remove all collaborators
• Delete a database
  • A reason must be set (random example from the GH DMCA repo: https://github.com/Wanjieming/IPTV)
  • Add an option to disable the account of the owner
  • Add an option to disable the accounts of the collaborators

Re: implementation. I think this should be implemented as a command that runs on the server (at least for now, we can revisit this in the future)

[marcua]

This is an excellent list, thank you @sofiaritz! I've updated the items in the description, but let me know if I missed any details.

Three items I didn't add yet because I'd like to understand them better:

• Revoking all tokens instance-wide: I haven't seen this in other systems, but would like to hear more. I'd imagine needing to do this means there's been some big security incident, and likely there will be several nuanced migrations/manual actions in that case that the sledgehammer command offers wouldn't be enough. I'm thinking of the CircleCI incident, for example, where despite keys being compromised, they still guided users through the key rotation process.
• Remove all collaborators: I'd imagine that as an administrator you would either want to remove one collaborator (which I imagine the permissions/sharing APIs would let you do) or to disable the database, but I'm not sure the scenario where removing all collaborators specifically would be necessary.
• I added "disable a database with a reason," but didn't add the options to disable accounts, since there's probably some nuance to the actions one would take and we'd have an admin command to handle each of the relevant owners/collaborators.

Makes sense on implementation. I keep hoping there will be some other project that provides a Django Admin-like administrative tool, but I can't find one. It's wild to me that we have to come up with this stuff for ourselves, and I'd love to find a way to avoid it :).

[sofiaritz]

Revoking all tokens instance-wide

I have in mind a case where an attacker has obtained access to something like the fernet key and a backup instance is started on another server while forensic analysis is going on. In that case the ayb instance is secure (the compromised box is turned off/being analyzed, but a backup one has been created using backup data), but all tokens are compromised (the attacker has access to the fernet key).
But in that case, changing the fernet key must be done and would effectively revoke all tokens (at least I think it would?).

Remove all collaborators

I forgot to write down the reason for this and I can't think of anything, you can remove it :p

but didn't add the options to disable accounts

In the case of something like illegal activities, the safest thing to do from a legal standpoint is to immediately disable access from all possible bad actors and then start investigating who really should have their account disabled.
For example, an admin receives a report of a database containing links to CSAM content. The right thing to do there is to disable access to everyone involved, delete the database and contact local authorities.

[marcua]

But in that case, changing the fernet key must be done and would effectively revoke all tokens (at least I think it would?).

That's right. As soon as you change the fernet key, any data (registration tokens) signed with the old ones will be "revoked" in the sense that they will not be accepted anymore. Since the fernet key is set in ayb.toml, there's no action we have to take from an admin command that I can think of.

For API tokens, we only store part of the token and a hash of the part we don't have in the DB, so even if one key is compromised, or if the DB itself is compromised, there shouldn't need to be any wholesale revocation.

I'm not a security expert, so definitely poke holes in this! :)

The right thing to do there is to disable access to everyone involved, delete the database and contact local authorities.

No pushback on the real-life action to take, I was more thinking it's not many steps to list collaborators and call the "Disable account" admin command on each. Since it wasn't many steps, I didn't want to add complexity to the implementation and have two different ways to disable accounts. I don't feel too strongly, and would be happy to look at the more complex implementation as well :).