Hi Rick, Does this mean that a pre-existing database will always be run with the knob off after hard-upgrade to 11.x release(or whatever the release number which will have the security features)? Or will "B) Security level" give users the option to use security features after hard-upgrade?
thanks, Mamta On Tue, Sep 20, 2011 at 8:09 AM, Rick Hillegas <[email protected]> wrote: > On 9/19/11 5:28 PM, Kathey Marsden wrote: >> >> On 9/19/2011 1:20 PM, José Ventura wrote: >>> >>> I'm not sure whether making the default value "on" will actually improve >>> security as a whole. If a developer hasn't given thought to security, there >>> are plenty of other pitfalls that may compromise an application (e.g. "where >>> should I store the (previously unneeded yet now required) username and >>> password?"). >>> >>> On the other hand, if s/he did in fact think about security, then odds >>> are that are a simple, concise documentation will point him/her to happily >>> turn on the switch with minimum nuisance, and proceed to secure the rest of >>> the application. >>> >> I think this is a very good point. The claim of "secure by default" is a >> very strong claim and may give a false sense of overall security. Some >> things, like encryption and perhaps stricter security manager settings are >> not part of the default, but might be an important part of actually securing >> a particular application. I agree it is good for the application developer >> to plan security and for us to make it as easy as possible for them to do so >> from a Derby perspective. >> >> Perhaps the conversation of the default is premature. Perhaps we should >> first nail down the easy security knob and understand its behavior and >> usefulness and then discuss whether it should/could be the default. >> Kathey >> >> >> >> > Thanks, talking about these details would be useful now. > > A) On/off switch - A simple scheme would be a property with two values. The > property is stored in the database at creation time, as is done with > derby.connection.requireAuthentication. Once stored in the database, the > property can't be changed. > > derby.security.basic=true > > This enables the initial set of security features which I included in my > first posting (copied at the end of this message). > > derby.security.basic=false > > This is the default for a pre-existing database. If no value for the > property is stored in the database, that is identical to a stored value of > "derby.security.basic=false". This gives you the wide-open security behavior > of the 10.x series of releases: none of the security features are enabled by > default and you have to configure each security feature individually. > > This is what I had in mind. However, more flexible schemes are possible. I > haven't given these much thought. Options (B) and (C) below have the > advantage that machinery will be in place if we need to add higher security > levels later on. > > ---------------------------- > > B) Security level - A more complicated scheme would be a property which > would allow you to dial the security level up and down. As with the on/off > switch, the property would be stored in the database at creation time. I > haven't thought about the implications of changing it afterward. > > derby.security.level= > > Can be set to one of the following: > > none This is the wide-open security behavior of the 10.x > series. > basic This enables the security features at the end of this > message. > encrypted This is basic plus encryption. > > If no value for the property is stored in the database, that is identical to > a stored value of "derby.security.level=none". > > C) Release level - A more complicated scheme would be a property which would > allow you to peg the security level to what was considered best practices > when a particular release was published. E.g.: > > derby.security.version=10.11.4.3 > > > ----------------------------- > > Here is the initial set of security features which would be enabled in 11.x > if the master knob were set: > > 1) Authentication - Will be on, requiring username/password credentials at > connection time. Derby will supply a default authentication mechanism. > > 2) SQL authorization - Will be on, hiding a user's data from other people. > In addition, Derby will support more SQL Standard protections for Java > routines. > > 3) File permissions - Will be tightened as described by DERBY-5363. > > 4) PUBLIC -This keyword will not be allowed as a user name. > > 5) SSL/TLS encryption - Will shield client/server traffic. > > 6) Server administration - Will require credentials. > >
