Security: An Overview

Team Fly

Page 120

Security features proliferate throughout today's computers. In fact, most anything larger than a single procedure can have some kind of security feature that can be adjusted by a user, an administrator, a programmer, or all three groups. As you'll see later in this chapter, programmers can even use .NET to specify security behaviors for single procedures.

There are all kinds of levels and varieties of security—and some of them conflict with each other, stepping on each other's toes. You find self-contained security feature sets in applications such as Internet Explorer, utilities, the operating system, networks, databases and database languages, servers, Internet applications, languages such as VB.NET and ASP.NET, IIS settings, and so on.

There's a more-the-merrier quality to current computer security efforts—you find locks and bolts, checkpoints and identity verifications all over the place. If you've ever lived in New York or another large city, you probably know someone whose idea of increasing security is to add yet another deadbolt to the 12 locks they already have on their apartment door. Doors in big city buildings are like Houdini's escape-proof suit—straps, chains, alarms, sliders, and what have you.

And if you've ever struggled to get your .NET prototype applications working with a database or SQL Server, for example, you've entered the security house of mirrors.

Obviously, security isn't something that is designed to be easily circumvented—by definition, security measures are supposed to be, if not obscure, at least somewhat difficult for the average user to understand and manipulate. You're not supposed to have a helpful message box pop up saying ''You need to adjust your logon identity permission level before you can access this database. To make this adjustment, choose Start Programs Microsoft SQL Server Enterprise Manager. Expand the Security node, then click Logins to see the list of users who are permitted to log into SQL Server. If you have this permission, take the following step ...."

No, you have to dig around to figure out that in addition to your Windows role (the security group you belong to, as identified by your logon name), you have another, separate role to define with SQL Server. If you're told that you don't have permission to create a connection to a particular database, you have to get down and give yourself permission.

Beyond Windows and SQL Server, there are yet other layers. For example, when VB.NET's managed code is expected to work with SQL Server, then SQL Server's security apparatus comes to life and, possibly, denies access on this level. Perhaps you're running an application that doesn't have permission (or doesn't grant permission). Perhaps a particular file is set to read-only. The list goes on.

Some security settings are specified by the user, such as adjusting which macros Word allows to execute, or whether or not Outlook Express warns you about executable attachments to e-mail.

Other security settings are under the control of administrators, the IT professionals who look after the safety of workplace operations. Still other aspects of security are managed by developers and programmers who can specify various levels of access and permissions right within their applications' code.

Nearly all of the various types of access security, though, come down to one thing: Who is this user, and what exactly do they have permission to do? The answers to these questions fall mostly to what's called role-based security, and the key to role-based security is the administrator—the person or persons with total access to a computer or network, and the one who defines everyone else's role (or "level of trust," also known as permissions). Anyone who can figure out how to gain administrator status can run riot.

Team Fly