-Language-
Implementing Security Access Control (SAC)
2016-12-30 17:26

Security access control (SAC) is an important aspect of any system. Security access control is the act of ensuring that an authenticated user accesses only what they are authorized to and no more. The bad news is that security is rarely at the top of people's lists, although mention terms such as data confidentiality, sensitivity, and ownership and they quickly become interested. The good news is that there is a wide range of techniques that you can apply to help secure access to your system. The bad news is that as Mitnick and Simon (2002) point out “…the human factor is the weakest link. Security is too often merely an illusion, an illusion sometimes made even worse when gullibility, naivette, or ignorance come into play.” The go on to say that “security is not a technology problem – it’s a people and management problem.” Having said that, my experience is that the “technology factor” and the “people factor” go hand in hand; you need to address both issues to succeed.


This article overviews the issues associated with security access control within your system. Although it includes a brief discussion of authentication, the primary focus is on authorization, assuring that users have access to the functionality and information that they require and no more. The issues surrounding authorization are explored in detail as well as both database and object-oriented implementation strategies. As with other critical implementation issues, such as referential integrity and concurrency control, it isn’t a black and white world. A “pure object” approach will likely prove to be insufficient as will a “pure database” approach, instead you will need to mix and match techniques.

1. Authentication

Authentication is the act of determining the identity of a user and of the host that they are using. The goal of authentication is to first verify that the user, either a person or system, which is attempting to interact with your system is allowed to do so. The second goal of authentication is to gather information regarding the way that the user is accessing your system. For example, a stock broker should not be able to make financial transactions during off hours from an Internet café, although they should be able to do so from their secured workstation at their office. Therefore gathering basic host information, such as its location and security aspects of its connection (is it encrypted, is it via a physical line, is the connection private, …), is critical.

There are several strategies that you can follow to identify a client:

User ID and password: This is the most common, and typically the simplest, approach to identifying someone because it is fully software-based.

Physical security device: A physical device, such as a bank card, a smart card, or a computer chip (such as the “Speed Pass” key chains used by gas stations) is used to identify a person. Sometimes a password or personal identification number (PIN) is also required to ensure that it is the right person.

Biometric identification: Biometrics is the science of identifying someone from physical characteristics. This includes technologies such as voice verification, a retinal scan, palm identification, and thumbprints.


2. Authorization

Authorization is the act of determining the level of access that an authorized user has to behavior and data. This section explores the issues surrounding authorization, there is often more to it than meets the eye, and then explores various database and object-oriented implementation strategies and their implications.

2.1 Issues

Fundamentally, to set an effective approach to authorization the first question that you need to address is “what will we control access to?” My experience is that you can secure access to both data and functionality, such as access to quarterly sales figures and the ability to fire another employee respectively. Your stakeholder’s requirements will drive the answer to this question. However, the granularity of access, and your ability to implement it effectively, is a significant constraint. For example, although you may be asked to control access to specific columns of specific rows within a database based on complex business rules you may not be able to implement this in a cost effective manner that also conforms to performance constraints.

The second question that you need to answer is “what rules are applicable?” The answer to this question is also driven by your stakeholder’s requirements, although you may need to explore various security factors that they may not be aware of (they’re not security experts after all). These factors, which are often combined, include:

Connection type

Update access

Time of day

Existence

Cascading authorization

Global permissions

Combination of privileges

2.2 Database Implementation Strategies

Let’s start by reviewing the concepts of roles and security contexts. A role is a named collection of privileges (permissions) that can be associated to a user. So, instead of managing the authorization rights of each individual user you instead define roles such as HR_Manager, HR_User, Manufacturing_Engineer, Accountant, and so on and define what each role can access. You then assign users to the roles, so Sally Jones and her co-workers would be associated with the role of Manufacturing_Engineer. Someone else could be assigned the roles of HR_Manager and HR_User if appropriate. The use of roles is a generic concept that is used by a wide range of technologies, not just databases, to simplify the security administration effort.

A security context is the collection of roles that a user is associated with. The security context is often defined as part of the authentication process. Depending on the technology used a security context is maintained by the system, this is very common in GUI applications, or must be passed around by the system, something that is common with browser-based n-tier system. A combination of the two strategies is also common.

Authorization can be enforced within your database by a variety of means (which can be combined). These techniques include:

Permissions. A permission is a privilege, or authorization right, that a user or role has regarding an element (such as a column, table, or even the database itself). A permission defines the type of access that that is permitted, such as the ability to update a table or to run a stored procedure. In SQL, permissions are given via the GRANT command and removed via the REVOKE command. When a user attempts to interact with a database his or her permissions are checked, and if the user is not authorized to perform part of the interaction, which could be a transaction, the interaction fails and an error is returned.

Views. You can control, often to a very fine level, the data that a user can access via the use of views. This is a two-step process. First, you define views that restrict the tables, columns, and rows within the tables that a role can access. Second, you define permissions on those views.

Stored procedures. Code within the stored procedure can be written to programmatically check security access rules.

Proprietary approaches. A new option being offered by some database vendors is proprietary security tools. One example is Oracle Label Security, an add-on that enables you to define and enforce row-level permissions.

The primary goal of database security is to ensure that there isn’t any “backdoor” ways to access critical corporate data. Many organizations choose to disallow ad-hoc queries to production databases to help minimize the chance of unauthorized access (as well as to avoid the associated performance problems). Many organizations introduce reporting databases such as data marts to support ad-hoc queries.


3. Effective Security Strategies

I’d like to share a few words of advice that have worked well for me over the years:

Base your security approach on actual requirements.

Strive for an enterprise security strategy, but be realistic.

Don’t overdo security

No security approach is foolproof

Give people only the access that they need

Limit permissions to a small set of hosts

Remember performance

Don’t forget other security issues such as audit control and logging

Adopt industry standards


Stephanie Stephanie Stephanie Ellie Ellie Ellie Victoria Victoria Victoria Olivia Olivia Olivia Isabella Isabella Isabella Jayden Jayden Jayden Lucas Lucas Lucas Dylan Dylan Dylan Ryan Ryan Ryan Noah Noah Noah

Sweep the concern Yingze electronic official WeChat

x
Sample Apply
※ Please fill in your information, our company will deal with your problem as soon as possible.