We’ve been trying to understand if Google Cloud can access data stored in Google Storage when using Google-managed encryption keys.
We want to understand if Google potentially has access to the data stored. If yes, is there a way to restrict such access?
Yes, Google can. No, you cannot restrict Google.
Google publishes data policy documents on its website on how/when/if they access your data. Data access is logged so that you can see such accesses. There is a process requiring approval. A Google employee cannot just poke around in your data. Similar to most legal documents, you must read the documents to understand the details and conditions.
Start with this privacy page:
Privacy Resource Center
Related
I have an iOS App. Would like to explore what is needed to be done to achieve the following:
1) The user taps on the map
2) US Census Tract info is requested from database
3) Later the user wants to purchase this tract info.
The US Census Tract info would be uploaded to Cloud Object Storage.
There are 70,000 Tracts grouped by US States = 50 + 1 (DC)
I could use SQL Query to select one Census Tract by its ID.
In the iOS App I can use Apple Login and get users' name and email.
The question is how to grant/revoke access to this info automatically
after in-app purchase?
The question is two-fold. Do I have to create 70,000 CSV files and grant them an access to? Or this can be achieved dynamically with SQL?
The second part is - how to automate this process?
Does IBM Cloud has this capability?
I would expect that you would use a single Service ID that would have access to the data sitting in COS, and that a user's access to the underlying data would be handled in your application logic. The Cloud IAM access policies are not intended for end-users as much as for internal development/operations teams to manage access to various cloud resources.
Depending on the format of the census data, SQL Query could be a great way to do it. You could use SQL query to create a new object with the subset of data the user has requested, and then create a presigned URL that will expire in a whatever timeframe is reasonable, allowing the file to be downloaded to the client device.
I need to store my service data in Google Storage and let my users download files depending on their (users) access rights.
I've already made service that connects to Google Storage using server-centric mechanism, and transfers them to client-side, but I need client-side to go to Storage and download file without server-side.
I've tried to use temporary links for files, but I can't check, if user downloaded file or not to properly delete temporary link.
I've tried to look for oauth2 support, but it seems Google doesn't support oauth in such way (When my service decides to allow access or no).
The best solution is to generate tokens for users and if Google Storage would call my service before every file download.
How can I achieve that?
I'm quite new to Cloud Storage solutions, and I'm currently researching options to upgrade our current solution (we currently just upload on a SVN server).
What I have is a native application running on client computers, which will upload data to the Cloud Storage. Afterwards, client should be able to download and browse their data (source is not set in stone, could be a website or from other applications). They should not be able to access other user's data.
I'm not sure how I'm supposed to proceed. As far as I understand, the native application will upload using a Native Application Credential, using JSON.
Do I need multiple credentials to track multiple users? That seems wrong to me. Besides when they come back as 'users' through the web interface, they wouldn't be using that authentification, would they?
Do I need to change the ACL of the uploaded files afterwards?
Should I just not give write/read access to any particular users and handle read requests through Signed URLs, dealing with permission details by myself using something else on the side? (not forcing a Google Account is probably a requirement)
Sorry if this is too many questions, and thanks!
Benjamin
The "individual credentials per instance of an app" question has come up before, and unfortunately there's not a great answer. If you want every user to have different permissions, you need every user to be associated with a different account.
Like you point out, the best current answer, other than requiring users to have Google accounts, is to have a centralized service that vends signed URLs to the end applications. That service would be the only owner of all of the objects and would give out permission to read or upload as needed.
I have a newbie question regarding google cloud storage. I'm looking to create a website where people can upload files (similar to Flickr in concept) and view them. I was looking at google's cloud storage option and it seemed interesting. I got a little hung up on the authentication process. Do all users need a Google account or did I just misread it? I guess my question is can I create a site where everyone doesn't have to sign up for a google account?
Thank you for your patience and help
Nope, there's no need for customers to have their own Google accounts. Google Cloud Storage supports that, in case you want to say "these accounts have access to this data", but you can also let your app grant access on a per-request basis using whatever logic or authentication scheme you like.
This is usually accomplished with signed URLs. Basically, you'd use your credentials to sign a very specific request (download object X, upload an object with name Y) and pass that URL to the user for them to use. Signed URLs are only valid for as long as you like (one of the parameters is how long the URL is good for).
Documentation on signed URLs are here: https://developers.google.com/storage/docs/accesscontrol#Signed-URLs
It's not strictly necessary to require a user to be logged in in order to write to your bucket (e.g., we have a public-read-write canned ACL for buckets), but it's generally a bad idea. Any data stored in your bucket will ultimately be charged to you, so allowing anyone to write without authentication opens you up to a great deal of abuse.
Likewise, you could make all of your objects public-read, but then you get charged for the bandwidth costs and have no control over it (though this is a much more reasonable thing to do than public-write).
A safer option would be to proxy bytes for your users - i.e., only you/your app can write to your bucket, and your users hand their bytes to you.
Generally speaking, though, the only types of authentication we support are Google accounts, signed URLs, and anonymous users.
I'd like to use Amazon SimpleDB to store data for my iPhone app. Different users will own items within the same domain. I'd like for users to be able to delete their own items but not each others', and for this restriction to be enforced server-side.
I am hoping to use anonymous TVM.
What is the best way to do this?
Using IAM User Management you can create a custom policy for each user or group to allow or deny access to delete items in SimpleDB. If each user has their own domain you can restrict access to the domain by using the arn format arn:aws:sdb:<region>:<account_ID>:domain/<domain_name>
I think that you can't use IAM - you seem to say that you have one domain where all user data is stored.
One way to achieve what you want is to use item name prefixes that are user based, e.g. user jimsmith would have all items stored under an item name that beings with 'jimsmith' or some random string, unique to jimsmith (which could be stored somewhere).
Then you are in charge of security, so you would not be able to have the phones directly query AWS - they would need to talk to your intermediary server which would handle security. You have to assume that people could run the app on a jailbroken phone, and decompile, etc.
You can use IAM to restrict a single user to a small portion of an S3 bucket though. You could then index the bucket using a server app of your design. Then the DB could be used for searching purposes with your own code, so that iPhones only deal with S3.
From what I have researched the simpleDB user right policies aren't designed to be used in such a way you are proposing (meaning undisclosed number of users of the app) and the way to handle this might be to use some server application in-the-middle as was suggested here: Mobile app and SimpleDB direct 'Access Policy'