Brief introduction
The problem we face is that the topic of database security has not been as compelling as the world record and report for the shortest downtime. When was the last time you read a smart article about security tokens and encryption? But as the last year's hype about the theft of credit-card numbers from some e-commerce companies shows, the security gap is indeed striking – and it can weaken customer confidence. Even if security is not the most exciting topic, it is also an important concern for any enterprise that uses a database management system. At the same time, as more and more enterprises participate in the electronic space, it is very important to separate the private data from the public data.
For more information on DB2 UDB security features, refer to DB2 administration Guide.
The database system of any given company may collect, store, and analyze thousands of lines of information, which are both public and private in nature. Because of this responsibility, the database must enable the database administrator to properly authorize and restrict access. In addition, the database must provide methods to prevent unauthorized users from accessing confidential data.
But sometimes, database security information is difficult to obtain or understand. Although you often hear how scalable and robust the DB2 Universal database (DB2 Universal database,udb) is, how often do you hear about the security features of DB2?
Because securing database security is one of the most important responsibilities of a DBA, you should not attempt to learn database security through repeated experimentation. Protecting your database security involves:
Prevent unauthorized access to confidential data by an enterprise without knowing it
Prevent unauthorized users from malicious deletion to destroy or change data without authorization
Monitoring user access data with audit technology
In this article, I'll take you through the security features in the Windows, Unix, and OS/2 versions of the DB2 UDB v.7.1, and describe some of the internal controls that can help you maximize security.
Verify
One of the most basic concepts in database security is validation, which is a fairly simple process through which the system verifies the identity of the user. Users can respond to authentication requests by providing an identity card or authentication token.
It is likely that you are already familiar with this concept. If you have ever been asked to show an ID with a photo (for example, when you open a new account with a bank), you have already been presented with a validation request. You show your driver's license (or other photo ID) to prove your identity. In this case, your driver's license acts as a verification token.
Figure 1. DB2 Authorization role
No matter what you see in the movies, most software programs cannot use future systems (such as facial recognition) for validation. Instead, most authentication requests require you to provide a user ID and password. Your user ID indicates that you are claiming to be a person authorized to access the environment, and the password will provide your personal verification evidence. Of course, this validation assumes that your password is well protected and that you are the only person who knows the password.
User authentication is done by a security tool other than DB2, which is usually part of the operating system or a stand-alone product. In fact, security is not just a database problem; Operating system vendors also spend a lot of time, money and effort to ensure that their products are safe. However, some operating systems, including Microsoft Windows 95 and 98, do not have local security mechanisms. If you are using an operating system that has no security, you can configure the environment to rely on DB2 servers running on a more secure system to provide this security. For example, you can use reliable client options, and I'll discuss these options more later in the article. (For more information, please refer to DB2 Administration Guide.) )
You can also add a layer of security to your environment using third-party products, such as the Distributed Computing environment Security Service defined by Open Group (distributed Computing Environment (DCE). DB2 can coordinate these external security efforts with their security initiatives to protect the transaction or analyze the environment.
Once the user authentication succeeds, DB2 notes the user's identity and other related security information, such as a list of user groups. The user must use either the SQL authorization name (authorization name) or the authorization identification (AUTHID) to be DB2 recognized, and the authorization name or authorization identity can be the same as the user identity or the mapping value. This connection information will be retained during user connections.