As Tardigrade can be considered secure cloud with its default encryption, maybe there are ideas how to make it even more secure to lower the risk of unwanted exposure of potentially sensitive material?
Also in the article there is a AWS emergency response team mentioned. Does something similar exist for Tardigrade? A team or person that can be contacted so a potentially dangerous situation can be resolved quickly?
I was thinking what additional features or improved usability could be implemented to avoid such leaks.
I am just brainstorming here:
Dashboard improvements with warning or red flags if there are unsecured buckets.
Access limits like the proposed number of downloads, but also IP based restrictions
Emails to owners if they have unsecured buckets
Secure default settings that a user has to actively opt-out
I think the worst cases are with users, that leak their information without intention. So some sort of frequent status report to them about the accessibility of their buckets might help a lot.
We do not have an access to the customerās data, include encryption and permissions (itās encrypted by the encryption keys derived from the encryption phrase. We do not store an encryption phrase, it is never leave the customerās devices).
Thus we cannot see is it encrypted or not. Even in the Satellite UI we can list only names of the buckets (if the names of the buckets are not encrypted too), not the content or permissions.
We also cannot check are they shared or not without having your access grant, but we do not have an access to customersā access grants before they are actively specified by the customer. Only the access grant allows you to get an access with encoded permissions.
So, the p.3 is not possible too - we have no idea, which of buckets/projects are shared without having an access grant explicitly specified by the customer.
The p.4 is already done. By default none of the projects or buckets are shared, so they accessible only to the customer. You should explicitly generate an access grant with all needed permissions.
The uplink share will generate an read-only access grant by default. To give more permissions, you should actively specify them.
Very interesting. So basically the satellite has zero knowledge?
So in a case of unintended leakage Storj has also no way to revoke permissions or undo a linkshare on a customers behalf? Like it was mentioned in the article this is what AWS did?
I partly disagree here. When I create an Access Grant all permissions are set and all buckets are selected and duration is set forever everything preselected by default.
That is exactly the opposite from secure default settings.
But when I create an Access Grant I need to give it a name.
When the Access Grant has been created I can no longer see permissions or bucket name or anything about it. That alone is bad.
Would it not be possible to add automatically the permissions to the name of Access Grant?
So if I choose name ābucket_123ā the system adds automatically the access permissions, so that it gets stored as name ābucket_123_download_upload_list_deleteā or something like that.
It sure looks ugly like hell but you get the idea?
The leaking in the Tardigrade network is possible only when the customer would publish their access grant or linkshare. Itās includes an access grant and It should be possible to revoke it. But Iām not sure, how to do that. The access grant can have a very granular permissions like one object with only write permissions (even without a list and delete permissions).
I think you mean a new Access grant wizard in the Satellite UI. Thatās a good point!
When you created a bucket it has default permissions which you specified in the access grant in the setup. Then you can share this bucket with other permissions (but they cannot be wider than a root access grant).
If you have a token (the base of the access grant), you already have a full access to your project. Then you can specify the encryption phrase (āContinue in the Browserā), permissions to the existing buckets or to the project (in case of All option).
However, if you used an access grant with only write permissions to create a bucket and upload an object, you can see only the bucket, but not content.
So, all depends on how you created an access grant. You even can generate an access grant in the satellite UI, which will not allow you to see a content of existing buckets (for example - you can specify a different encryption phrase or do not allow listing and/or read).
You can name it like that. And I did to be honest
However itās only a link to the hash in the database anyway. You can specify a different name for the access in your uplink like
Sorry I mixed Access Grants and buckets in my post.
I meant the following:
I create an Access Grant and select everything to my liking. But when I look into the list of Accces Grants, there is basically zero information what my Access Grant is doing. No information about the bucket, non information about permission.
You are saying that the satellite does not know about it, so it cannot be displayed.
So keeping an order of Access Grants relies on the customer and basically on a good naming scheme so he can follow up on everything. Now we all know this is a fiction.
When I created an Access Grant I quickly realized and named my Access Grants like: ātest_upload_listā.
Now this is why I wonder if something like this could not be automatically implemented. So that when looking at the list of Access Grants it becomes immediately clear what permissions come with them.
So what I mean is: When creating an Access Grant, couldnāt the name automatically be saved as name + permissions, like: āname_upload_list_deleteā.
This would at least give a quick overview about what permissions are currently set.
Of course in a perfect world the user would also be informed about what buckets these permissions are set.
So I hope it is clearer now and sorry for confusing buckets and Access Grants.
Yes. In the satellite we do not store that information, only hash of the access grant. When you use the access grant the satellite give you an encrypted metainformation related to the hash of the access grant. Then uplink is able to decrypt it and have an access only to what you allowed to do.
However, you cannot see even in the uplink CLI what permissions the access grant have. You can request this feature too.
With uplink access inspect you can see a satellite, an API key (now called ātokenā in the Satellite UI) and encryption key (derived from the encryption phrase, so even there the encryption phrase is not exposed).
Personally I do not like to have a such pre-generation as a user and also it concerns me, that if the database of satellite could be stolen, someone can figure out the purpose of that exact hash. Iām not a hacker and have no idea, how to use it though.
From the other side, it is stored in the metainformation, so itās encrypted anyway.
Ok, let me think about this for a little bit longer.
After reading that article I believe there are some areas where improvement should be made to make it easier for customers to prevent unintended leaks. This includes creation of Access Grants, information about existing Access Grants, limits of Access Grants and in case of severe leakages, ways to shutdown a link even on behalf of a user.
Maybe others have some ideas on this too.
Edit: I have just created another Access Grant through satellite UI. And without any information displayed there it would require a strict naming scheme covering all necessary information. Something like: AG1_bucket_test1_list_delete_upload_7days or AG2_bucket_ABC_upload_forever etc.
Oh! If someone could stole my creds to the satellite UI, it will see those names! But they will not know my encryption phrase, so it will be useless anywayā¦
I do not know, but I do not like it anyway
But if you are able to store the names of the Access Grants in the satellites database, you would be able to store the corresponding permissions as well.
Of course you would have to transmit them from the client to the satellite when the user sets the permission / creates the Access Grant.
With such a change you should be able to display the permissions for each Access Grant in the list of Access Grants for the user which would improve manageability greatly and reduce therefore risk of unintentional exposure.
The permissions are part of the encrypted metainformation, itās not possible at the moment to get them from the satellite database without knowing your API key (token) and encryption phraseā¦
Yes, you would have to store them plain text in an extra column in the satellites database or something. The same way you store the name of an Access Grant in there.
That should be no problem and technically possible.
