> 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 would > > occur by someone making a mistake in admin console (when you can only > > query customer datastores in isolation). > > > It seems to me you are saying that if there is *any* mechanism that > > could compromise customer data, then why bother worrying about it? > > > There is a *lot* of work for GAE to do to get to the point where an > > app on their infrastructure can make a claim like that - e.g. I can't > > believe only 6 people have starred this issue for example - > > >http://code.google.com/p/googleappengine/issues/detail?id=501 > > > I suspect it is because people only look at the first page of issues - > > which completely debunks the idea that Google should be using stars in > > its issues list to prioritise its work schedule. > > On Dec 22, 4:47 pm, Andy Freeman <ana...@earthlink.net> wrote: > > > > > > Are you ok with the constraint that a query can not be run across > > > > multiple data stores? If we can agree on that, then I'd say we are > > > > doing pretty well. > > > > 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. > > > > No, such a query doesn't run in the application itself. However, a > > > query in an application that validates the user, determines which > > > datastore to use, and then runs all queries within that datastore also > > > doesn't access multiple datastores even if it does use an API feature > > > that could be used to access multiple datastores if said application > > > were written differently. > > > > I still have no interest in running a query across multiple datastores > > > and have never suggested otherwise. > > > > I'm trying understand why a feature that lets the application > > > programmer determine which datastore to use is an unacceptable way to > > > support "one code base, customer-specific datastores" if it's okay to > > > have an admin console and/or applications that have an admin user. > > > > Yes, it's convenient to have google manage all login stuff, but that > > > means that you don't have any control. If they're your customers.... > > > > On Dec 22, 4:25 am, hawkett <hawk...@gmail.com> wrote: > > > > > > > You use the example of maintenance and fixes > > > > > > on behalf of customers - when would that require querying across two > > > > > > customer's data stores? > > > > > > I never said or implied that it did. > > > > > Issue 106 proposes '...cross app queries using the db APIs only' - > > > > which to me means you can easily introduce a bug like the one > > > > originally posted - i.e. querying across two customer's data stores. > > > > Apologies if I understood your responses to be in support of this > > > > approach when they were not. Perhaps you could elaborate your use > > > > case in a little more detail. > > > > > Are you ok with the constraint that a query can not be run across > > > > multiple data stores? If we can agree on that, then I'd say we are > > > > doing pretty well. > > > > > For accessing another application's data store from your code, I would > > > > (and have) recommended exposing an API that you can access via HTTP. > > > > I believe this is what Google has suggested in this post > > > > >http://groups.google.com/group/google-appengine/browse_thread/thread/... > > > > > which is quoted in Issue 106. > > > > > If you do have a use case where you do want/need to run queries across > > > > customer data stores, then I would have that customer data in the same > > > > data store - i.e. what do you need the partition for in the first > > > > place? > > > > > Unfortunately the idea of a data partition and an application > > > > partition are the same thing at the moment with GAE, so perhaps you > > > > need the partition for quota and billing purposes, which forces you to > > > > have separate data stores when you don't want them. In that case I > > > > would raise a feature request for multiple applications to be able to > > > > share a single data store - would this satisfy what you are trying to > > > > achieve? > > > > > On Dec 22, 3:03 am, Andy Freeman <ana...@earthlink.net> wrote: > > > > > > I'm paraphrasing you. You've written repeatedly that a feature that > > > > > allows an application to choose the datastore on which it operates can > > > > > not be used for your purposes. The argument appears to be that an > > > > > application that uses such a feature can theoretically access multiple > > > > > datastores and is therefore unacceptable, even if that application is > > > > > written so it validates the user and then chooses which datastore to > > > > > access and only accesses one datastore after doing so. > > > > > > However, you're happy if a user's data can be accessed through a > > > > > google admin console or via an admin user. > > > > > > The reason that I find that distinction strained is that GAE > > > > > applications and the google admin console can be driven > > > > > programmatically. As a result, one can easily write code using those > > > > > facilities that simultaneously accesses multiple datastores, which is > > > > > your reason for rejecting the "choose which datastore to access" > > > > > feature. > > > > > > > You use the example of maintenance and fixes > > > > > > on behalf of customers - when would that require querying across two > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
