> In fact, given that Google already > have a data partitioning mechanism for applications, I wouldn't be > surprised if it was even lower level than the GAE platform, and part > of the BigTable implementation.
You're hoping that the partitioning for a given datastore depends on how google allows access to said datastore. In particular, you're hoping that the partitioning for datastores using a feature where a given application can pick between a set of datastores is different than the partitioning when a given application has access to exactly one datastore. That's unlikely. If google decides to implement such a feature, it would be silly to also introduce a different mechanism for partitioning datastores. > How would they even begin to assess the risk profile - do > they have to audit your company's development practices? If your customers are serious, they must, regardless of how your application is deployed, regardless of who handles login/access management. Login code isn't the only risk. And, if you're serious about login code, you must validate the login result. That is, once it is determined that a given user running your application should use a given datastore, the application then must look the datastore that it is trying to use and verify that it is actually the correct datastore for that user. Platform login code can't do that check. And, the platform's login doesn't provide much information to the application for it to do such a check. Yes, I realize that customers have different risk and cost sensitivities so there must be some right around the points that you like. However, that's a long way from saying that such points dominate. On Dec 22, 2:03 pm, hawkett <hawk...@gmail.com> wrote: > > No, I don't agree. Even if we ignore the admin console hole, "strict > > data partitioning" is a fantasy in an environment where data lives on > > the same hardware. The google code for handling multiple datastores > > could go wonky. Or, their user login code could do the wrong thing. > > I think you are making a number of mistakes - > > 1. Believing that the risk profile of platform code is the same as > your application code (and the 1000's of other developers that roll > their own data security solution because it isn't part of the > platform). If Google offers it as part of the platform, then it has > been tested by those 1000's of developers, by their customers and by > Google as a major part of a strategic platform offering by a company > with enormous resources. You state - 'Since the risk of your login > code doing the wrong thing is unacceptable, it's unclear why the risk > of their code doing the wrong thing is any more acceptable' - it is > *absolutely* clear that the risks are not even in the same ballpark. > > 2. Not seeing it from the customer's perspective. What they see is > that every app on GAE is a roll your own data security effort - what a > nightmare - how are they to tell which app was written well and which > wasn't? How would they even begin to assess the risk profile - do > they have to audit your company's development practices? If Google > offers it as part of the platform the customer knows that every app > shares the same implementation, and (assuming you agree with the first > point) a far less risky one. Maybe you can write more or equally > stable code than Google, but the customer has know way of knowing that > - I'll bet you that 100% of customer's that approach you for the first > time would rather hear that data security is supplied as part of the > Google platform than by your application code and not because "that's > nice" - but because this feature *does* affect the real security of > their data. > > 3. Thinking strict data partitioning "is a fantasy in an environment > where data lives on the same hardware". I did say strict, not > physical. I think you are missing the value of the software platform > again - it is not the same thing as application code that runs on the > platform. You appear to be making a simple distinction between > hardware and software. The application platform is inherently more > robust than your application code. In fact, given that Google already > have a data partitioning mechanism for applications, I wouldn't be > surprised if it was even lower level than the GAE platform, and part > of the BigTable implementation. That would make it even more robust > than the GAE platform code. Which is ludicrously robust compared to > your application code. > > 4. Thinking risk reduction is not valuable unless it results in total > risk removal. Security is all about the management and mitigation of > risk - not necessarily the removal of it. Remove it if you can, > obviously - but generally this is an unlikely outcome. We've > identified three threats (admin console error, external app doing > admin, bug in application code) - and you are saying that unless we > remove the first two, why remove the third. It's false logic, and > poor security. > > 5. Confusing a admin error or malicious attack with a software bug. > You state - "My point is that that's not true. If I have access to > multiple admin consoles (for maintenance reasons), I can combine the > results that I get from each of the consoles, effectively giving me > the ability to query against multiple datastores. I can do this with a > program that > 'runs' the admin consoles or I can do it by hand". Can you point me > to the admin console API you'd use to 'run' it via a program - or are > you talking about screen scraping? Both situations are totally > different scenarios, and risk profiles, to being able to introduce a > bug into your application code that exposes customer data. > > 6. Thinking that with strict data partitioning you *will* be able to > introduce a bug into *your* application code that exposes multiple > customers data to multiple other customers via the Datastore API. And > this is the key - from the customer's perspective - yes they have to > worry about an admin error, or some secondary application you might > write, or a malicious attack, or a defect in the platform code, or a > disgruntled employee - but they don't have to worry about the > application code they use every day, and that is one of their biggest > risk points eliminated - the largest part of your company offering. > Security is about risk mitigation and management. If you still > disagree, can you please explain to me how the bug would manifest in > your application code (I'm talking about code that runs on GAE, with > strict data partitioning). > > In the end, I think it all comes down to point 1, and an understanding > that software security is all about risk mitigation and management. > Control what you can, have contingency for what you can't. If you > agree with point 1, then you understand my position. If you don't > agree with point 1, well, good luck to you. I think I've just about > exhausted the ways I have of expressing what I feel is a very obvious > point. > > On Dec 22, 7:30 pm, Andy Freeman <ana...@earthlink.net> wrote: > > > > > > For the admin console, I'm saying you can only use this feature to run > > > against each datastore in isolation. > > > My point is that that's not true. If I have access to multiple admin > > consoles (for maintenance reasons), I can combine the results that I > > get from each of the consoles, effectively giving me the ability to > > query against multiple datastores. I can do this with a program that > > "runs" the admin consoles or I can do it by hand. > > > > And I can't do that if administrators can run ad-hoc unsecured queries > > > across customer data stores. (well, maybe they are secured, but only > > > by your application code) > > > Since the console is application code.... > > > > Do you agree that the cited bug would not occur with strict data > > > partitioning, and could occur if issue 106 was actioned? > > > No, I don't agree. Even if we ignore the admin console hole, "strict > > data partitioning" is a fantasy in an environment where data lives on > > the same hardware. The google code for handling multiple datastores > > could go wonky. Or, their user login code could do the wrong thing. > > > Since the risk of your login code doing the wrong thing is > > unacceptable, it's unclear why the risk of their code doing the wrong > > thing is any more acceptable. > > > > And finally - I am looking for features that allow me to give my > > > customers confidence, not erode it. > > > That's nice, but the feature in question doesn't affect the real > > security of your customer's data. > > > If multiple customers have data on the same piece of hardware, some > > code has to manage the separation. If it's unacceptable for your code > > to do so.... > > > > It seems to me you are saying that if there is *any* mechanism that > > > could compromise customer data, then why bother worrying about it? > > > Not at all. I'm saying that if a given mechanism is an unacceptable > > risk under one name, it's an unacceptable risk under all names. I'm > > also saying that if you're putting in a screen door (admin consoles), > > it's somewhat silly to worry about weatherstripping said door. > > > On Dec 22, 10:21 am, hawkett <hawk...@gmail.com> wrote: > > > > > I'm okay with that constraint. My point is that if the application > > > > has an admin console or an admin user, one can write a query that runs > > > > across multiple datastores by writing code that accesses said > > > > datastores through their admin consoles and/or users. > > > > For the admin console, I'm saying you can only use this feature to run > > > against each datastore in isolation. Pick the datastore, run the > > > query. It's fair to say the admin console security model is another > > > problem that GAE needs to sort out > > > (e.g.http://code.google.com/p/googleappengine/issues/detail?id=91), but I > > > would hope that when it is sorted out, I can assign admin rights on > > > different data stores to different users in my organisation. > > > > For the admin user option, I am expecting that the admin user is > > > unique to each data store, not one admin user for all customers. The > > > picture I am painting is that you administer your customer data > > > instances individually, not as an aggregate. > > > > I want to be able to make a statement like this about my application > > > running on GAE (note especially the data security section at the > > > bottom) > > > >http://www.rallydev.com/products/deployment_solutions/security/ > > > > And I can't do that if administrators can run ad-hoc unsecured queries > > > across customer data stores. (well, maybe they are secured, but only > > > by your application code) > > > > And finally - I am looking for features that allow me to give my > > > customers confidence, not erode it. Saying that their data is > > > partitioned from other customer's achieves that goal. That doesn't > > > mean their data is perfectly safe - there would be any number of other > > > means by which their data could be exposed to their competitors, but I > > > can guarantee them that they their business plan is not going to > > > suddenly appear on the welcome screen of a competitor due to a bug in > > > my application code. The cited bug is a perfect example of this sort > > > of thing actually happening, and of a situation that would be closed > > > off with effective data partitioning. > > > > Do you agree that the cited bug would not occur with strict data > > > partitioning, and could occur if issue 106 was actioned? If you are > > > looking for a distinction, then this is it. To be perfectly clear, I > > > see this bug as an example of multiple customers having their data > > > exposed to multiple other customers - this is not a bug that > > ... > > read more »- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
