Authentication, Authorization, and Accounting - SecurityWhen we talk about “security” we know what we want, but describing it and making it happen can be different matters altogether. Network security has a natural conflict with network connectivity. The more an autonomous system opens itself up, the more risk it takes on. This, in turn, requires that more effort be applied to security enforcement tasks. This article is chapter eight of the book, Cisco: A Beginner's Guide, third edition, by Anthony Velte and Toby Velte (McGraw-Hill/Osborne, 2004, ISBN: 0072256354).
print this article SEARCH DEV SHED |
The framework for user-based security is called authentication, authorization, and accounting (AAA), pronounced triple-a. The AAA framework is designed to be consistent and modular in order to give network teams flexibility in implementing the enterprise’s network security policy.
Overview of the AAA Model AAA’s purpose is to control who is allowed access to network devices and what services they are allowed to use once they have access. Here is a brief description of the AAA model’s three functional areas:
Thankfully, the acronym makers put the three functions in sequential order, making the AAA concept easier to pick up: first, you’re allowed to log in (your identity is authenticated); then you have certain privileges to use once you’re in (you have predetermined authorizations); and finally, a running history is kept on what you do while logged in (the network team keeps an account of what you do). The philosophy is to let network teams enforce security policy on a granular basis. Most AAA parameters can be put into effect per LAN segment, per line (user), and per protocol—usually IP. AAA is a clearly defined security implementation framework that everybody can understand. The architecture is defined down to the command level. Indeed, the AAA concepts are actual IOS commands. Starting an AAA process on a Cisco device involves using the aaa prefix followed by one of the three root functions, such as aaa authentication. A whole AAA command line might read aaa authentication ppp RemoteWorkers tacacs+ local, for example. The purpose of AAA is to provide the client-side command structure on which CiscoSecure relies. AAA Modularity A security policy is a set of principles and rules adopted by an enterprise to protect system resources, confidential records, and intellectual property. It’s the network manager’s responsibility to implement and enforce the policy, but in the real world, security policy can get dragged down into the mire of office politics, budget constraints, and impatience. An end-user manager can have a lot of clout as to how the policy will be conducted on his or her turf. After all, the company, not the IT department, funds the network. Consequently, there can be a lot of variance among security policies—even within an enter-prise’s internetwork. This means that security policies must be highly adaptable. CiscoSecure tries to satisfy this need with modularity—the ability to separately apply security functions by secured entity, independent of how they are applied to other resources. The AAA architecture gives you the option to implement any of the three functions independent of the other two. This includes whether they’re activated on a device, which security protocol is used, and what security server or user database is accessed. Authentication Controls The aaa authentication command validates a user’s identity at login. But once you’re authenticated, exactly what can you access? That depends on the type of access being made:
Security must protect three destination environments: the Internet, the internetwork, and, most of all, the internal operating system of the devices over which internetworks run. Figure 8-3 illustrates access types and destination environments. The scenario of the network administrator logging into IOS devices is unique. In Cisco internetworks, that type of access is usually authenticated using TACACS+. Other types of access open into a Windows-or HTTP-based application service. Network administrators access a device’s IOS environment in order to perform device maintenance tasks. Users also require different dial-in services. Although almost everybody uses PPP nowadays, there still can be different requirements. Depending on the local network from which the call is made, different PPP services may be required, such as IP, IPX, NetBEUI, or just a plain terminal connection. Whatever the issues may be, different requirements often call for a variety of authentication methods to be used in the same internetwork. CiscoSecure lets the network manager employ any of the major dial-in protocols and authentication techniques. In addition, it supports the ability to apply these different tools by network interface or line—even on the same device. Authorization Controls AAA authorization limits services to the user. In other words, if authorization has been activated on a secured entity using the aaa authorization command users must be explicitly granted access to it. The person’s user profile is usually stored in the security server and sometimes also in the device’s local user database. When the administrator logs into the device and his or her user profile is checked, the device configures the authorizations to know what commands to allow the administrator to use during that session. Commands can be authorized by IOS command mode (the MyRouter> versus MyRouter# prompts) or by specific commands within a mode. Figure 8-4 lays out some of the various forms authorizations can take. Authorization can be more complicated than authentication. After you’ve been authenticated,the security server must supply the access device configuration information specific to the user—for example, which networks the user may access, which applications may be run, which commands are okay to use, and so on. Without centralized maintenance of authorization information, it wouldn’t be practical to assign authorizations byuser. (It’s hard enough just to keep usernames and passwords up-to-date.) Accounting Controls Accounting doesn’t permit or deny anything, but instead keeps a running record of what users do.AAAaccounting is a background process that tracks the person’s logins and network use. Figure 8-5 shows how AAA security accounting tracks resource usage.
Trends Leading to Client-Server Security Systems As with most network control systems, AAA uses the client-server model to manage security. In other words, there is a central security server holding the user profile information used by client access devices to enforce security. When a user makes a request to connect to a network, line, or service, the client device queries the server to check if it’s okay. Centralization is necessary because it’s no longer feasible to administer security one access device at a time; there are simply too many of them to keep track of. In the 1970s, a natural by-product of remote users dialing into central mainframes was that user security profiles (accounts, passwords, and authorizations) were stored right there on the same computer where all the services sat. This made it easy for the security system to check on user permissions. Then, in the 1980s, departmental minicomputers became popular, spreading computers out into the organization. Terminal servers were invented to provide the additional entry points the distributed topologies required, but user databases were now spread across many access devices—making it much tougher to maintain the security system. By the time IP-based networking took off, it became apparent that security information had to be centralized. Figure 8-6 depicts this trend. The rise of internetworking demands that an enterprise offer dial-in access throughout the organization. Doing so presents problems for enforcing consistent security controls across so many access servers. The AAA architecture is Cisco’s game plan for meeting these challenges. AAA’s Two Security Protocols: TACACS+ and RADIUS It’s possible to use AAA security on a stand-alone basis, with no central security database. In the real world, few do this because it would require the extra effort of maintaining security parameters on a device-by-device basis—a labor-intensive and mistake-prone proposition. IOS supports stand-alone security because, in some cases, a security server is unavailable—for example, in a very small internetwork or during the period of time when a security server is being implemented but is still not operable. AAA configures access devices as clients. Client devices include access servers, routers, switches, and firewalls. The clients query one or more security servers to check whether user connections are permitted. To do this, a protocol is needed to specify rules and conventions to govern the exchange of information. AAA security can use two protocols to handle client-server security configurations:
blog comments powered by Disqus |
|
|
|
|
|
|
|
/ 10 
