Storj provides multiple data access methods: "Linksharing" for public links, "Presigned URLs" for time-limited access, "Customer-specific S3 Credentials" for personalized encryption, and "Rotating Credentials" for broader time-restricted access. You can use your own application server to have even finer control. Each offers distinct security levels and benefits.
By incorporating Storj within your application server, you can exercise more granular control over data access, security, and governance. You essentially act as an intermediary between the client application and the Storj storage service. This approach offers a centralized method for controlling and monitoring data access. Below are some strategies for using or proxying Storj in the customer application server tier:
- Expose specific API endpoints that route to the various Storj services.
- Dynamically issue temporary credentials based on the user's role or other contextual information
- Caching Strategy to reduce the number of round trips to the Storj service or frequently accessed data
- Access Monitoring for auditing of access patterns
- Data Preprocessing for transformation or enrichment before storage or retrieval
Making data publicly available via Linksharing is very simple. There is the one-time need to register an intended bucket or path with Storj, after which this data in that bucket or path becomes publicly accessible for anyone who has the link. Because this public file sharing need only occur once, it is simple to do via the Storj Console (see Public Buckets), and need not be automated. Linksharing does not include the ability to upload files, but it may be used alongside other solutions.
Presigned URLs are a feature of S3 compatible cloud storage solutions. You can use presigned URLs to grant time-limited access to either upload or download an object. A presigned URL can be entered in a browser or used by a program to download an object. A presigned URL would be generated in your web service, and used browsers or clients using simple HTTP GET and POST commands. No S3 compatible SDK is necessary to use presigned URLs via browsers or code. Instead, Amazon's SDKs would be used on the web service tier to generate the presigned URLs. Presigned URLs have the advantage of allowing you to fine-tune your security needs. Because all customer requests to storage must first be authorized, you can create whatever logic and security scheme fits you best. The downside is that each file request incurs two round trips to web service, once for authorization and to create the presigned URL, and once to either upload or download the object. This make presigned URLs most popular for sharing files between users, or for performing uploads in applications dominated by primarily public viewing.
An alternative to presigned URLs is to create unique S3 credentials per-user. You can use Amazon's S3 SDKs. This SDK should handle all of the upload and download functionality.
If you opt for this solution, you may have one security credential for your administrative needs, and credentials for each customer. Customer credentials could use its own encryption passphrase, it you need to keep their data truly private . Each credential would also restrict permissions to a single customer bucket. Each customer credential can be enabled for S3 compatibility. A high level of our security / encryption implementation is located here. It's also worth looking at our multi-tenancy docs.
Whether you're using Linksharing or a global S3 credential, you can add time limitations similar to the use of presigned-URLs. Using rotating Linksharing credentials has some benefits over presigned URLs in that they can be generated for an entire application and apply to large number of files, rather than being be generated per request for each file.