What you could do is create a bucket with all Documents to which no-one has access. A microflow is used to retrieve the Document and creates a copy for the current user and stores it in another entity PersonalDocument, PersonalDocument has an association to the Account entity and thus has access rights. Right after downloading the PersonalDocument you delete it again, that way the link between the user and the Document are never stored.
The only problem i see is that you somehow need to provide the user with a 'key' that he can use to retrieve the PersonalDocument if the user is able to change this key locally then in theory he could brute force access to all documents.
But if you were to store the key in your database then you would implictly still have a way to link documents to users which you want to avoid in the first place.
Besides these two options i see no other way to achieve what you want.
Hi Rochus,
You can certainly create another entity called downloadDocument that is a specialization of personalDocument. Here you could grant read access rights to everyone, then make a copy of this and never commit it. Therefore there would never be anything in the table that users could see. You could even add [currentUser] access rules to this entity and then commit it so that the specific user could access all the documents they have downloaded. You could set the association to current user when you copy this from personalDocument to downloadDocument. That could work to meet this specific need.
However if you are looking for a 'best practice' here, I would strongly recommend reconsidering the policy that prevents an account from being associated. If you set this association and use it to drive security rules, then this is just as secure as creating a new entity and setting a new association I would think. I know a company policy is probably something that can't easily be changed but I don't think the existence of an association is a security risk when done properly.