>> You're hoping that the partitioning for a given datastore depends on >> how google allows access to said datastore
> Exactly - that is the feature request I am proposing. Huh? You were requesting the ability to spawn a new datastore and to have the login scheme for a given pile of application code pick the datastore. The above is about methods for separating datastores and whether the method for separating them should depend on how the datastore is chosen. > I don't agree. You should trust your authentication mechanism - this > is a trust relationship. If you don't trust it, then you need to > address that problem, not write additional application code which adds > to the complexity of your security implementation. Complexity in your > security implementation increases risk, not decreases it. Note this > is not an argument against defense in depth - it is an argument for > simplicity in each implementation layer. Let's look at these alternatives. With no post-login check, the application runs using whatever datastore the login procedure finds acceptable. If the login procedure fails or the datastore layer serves up the wrong datastore, the application still does its thing. Post-validate may catch either of those errors. (Of course, the post- validate could fail as well and allow access when it shouldn't, but that just leaves you no worse off than you were without the check.) Yes, the post-validate may block execution when it shouldn't, but that's likely to be because the datastore layer is misbehaving, delivering wrong data. The application may have failed eventually anyway when running with a misbehaving datastore layer, but detection during validation is better because the application doesn't get a chance to corrupt user-data. On Dec 24, 10:17 am, hawkett <hawk...@gmail.com> wrote: > > You're hoping that the partitioning for a given datastore depends on > > how google allows access to said datastore > > Exactly - that is the feature request I am proposing. It seems > likely to me that GAE uses a data partitioning feature of BigTable > (maybe not, I don't know, but to me it seems the right place to > implement a data partitioning function) - they should expand the way > GAE uses that BigTable feature to offer the functionality I am > requesting. > > > 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. > > Perhaps, but the threshold is significantly lowered - customers are > more likely to undertake an audit (rather than go to a competitor) if > they can see you are using platform features for security - I stand by > the assertion that 100% of customers who engage you for the first time > will prefer you to be using the platform over custom application code > - especially for security. > > > 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 > > I don't agree. You should trust your authentication mechanism - this > is a trust relationship. If you don't trust it, then you need to > address that problem, not write additional application code which adds > to the complexity of your security implementation. Complexity in your > security implementation increases risk, not decreases it. Note this > is not an argument against defense in depth - it is an argument for > simplicity in each implementation layer. We are talking about the > authentication layer, and the db access layer, and both should be > platform concerns, not application concerns (at least from my > perspective) - certainly they are currently platform concerns in GAE, > and I would like them to stay that way. > > It is very important to note that the functionality is *nearly* there > already - i.e. restricting access to users from a google apps account > - it has strict data partitioning, authentication and db access are > platform concerns, user provisioning administration etc. is already > there in google apps. The only thing missing is a method of > automatically spawning a new application in response to a customer > registration (and the 10 app limit). > > The architecture of GAE right now is totally in line with what I am > talking about, and I have no doubt that this is for all the reasons I > have listed, and many I haven't even thought of. Consequently I doubt > that you will ever be given the functionality you are looking for - > i.e. accessing multiple datastores from the same application instance. > > I'll ask again - would a feature that allowed you to map the same > datastore to multiple application instances satisfy your use-case? It > does stretch the data partitioning thing a bit, but might be workable > from a platform configuration perspective. > > On Dec 23, 7:22 pm, Andy Freeman <ana...@earthlink.net> wrote: > > > > > > 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
