Overview of RDBMS security concepts in client/server architectures

Can you please explain to me the RDBMS security concepts of client/server architectures?

    Requires Free Membership to View

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on the hottest data and information management trends today.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchDataManagement.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchDataManagement.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

I can certainly give you an overview – but security is, of course, a complex area, so this is just scraping the surface. Essentially, one of the “jobs” of the database engine is to look after the data. So any client application that tries to connect to a relational database management system (RDBMS) – i.e., the database server – has to supply some form of authorization to the engine. This is verified (or not) against a list of the users “known” to the engine.

Assuming that a match is found, the application is allowed to access the data appropriate for that user. Of course, it’s possible to create a user called “App” or something similar specifically for a given application and give that user the correct access rights for that one application. It’s also possible to put the security functions in the application itself. But as a database person, I would always work on the default assumption that the database engine should be controlling security.    

This was first published in August 2010