|
|
Since applications are becoming more distributed and the use of the Internet has exploded, it is apparent that security even to the level of data access is paramount and can no longer be taken for granted. In the remainder of this chapter, we will look at some security issues relating to data access.
To access a database, especially if you are designing a component or XML Web Service, you will need to have an account that the service can access. This is because the service is more or less public. Clients to the service will have no idea which user name or password they should use, and you should not try to set one for each client, especially considering that the potential number of clients can be huge. You will have to set one account that the service can use to access data on the database.
| Warning |
To protect your database, you must never use a hard-coded password. With the .NET Framework, there are management tools such as ILDASM.EXE, which parses .NET Framework EXEs and DLLs and shows readable information about the files. If you have a hard-coded password, it will be exposed. |
The security mechanism in .NET has been enhanced from previous versions of Windows. The classic object-based security (files, services) still exists, but now there is also code-based and evidence-based security. That means that a piece of code can be given security profiles defining which action it is allowed to perform. An administrator can also gather evidence to identify who and where a piece of code comes from. When designing your application, you will have to keep this in mind.
Currently on the Windows platform, most application information resides in the Windows registry. The .NET Framework was designed for the web and, as such, should be as platform independent as possible. The best practice in .NET suggests that application information reside in regular files instead of the registry.
|
|