Designing Security Architecture Solutions phần 3 ppsx

Security Architecture Basics 67 execute the decision algorithm as quickly as possible. Both of these goals may be in conflict with others such as speed of access definition review or administration. Any particular vendor solution will represent a unique set of compromises. For example, a model may store access rules for a subject in a set-theoretic manner: User X is ALLOWED access to {A,B,C,D,E} via one rule, but DENIED access to {C,D} via another. We have to compute the set difference between these two rules to arrive at a decision on a specific access request (“Can X read B?” “Yes”). We can view each access decision as combining all available data to arrive at a list of access control rules and applying a decision process to the set of rules. In general, when multiple rules apply to an access decision on whether a given subject in a given context can access an object, the policy must resolve the multiple directives into an acceptable decision. The resolution strategy should have the following properties: ■■ Consistency. The outcome of an access decision should be the same whenever all the parameters to the decision, and any external factors used in resolution, are repeated. ■■ Completeness. Every form of allowed access should correspond to an expected application of the security policy. The resolution algorithm must, of course, correctly implement policy. The modes of resolving multiple rules fall into one of three options. ■■ First fit. The access control rules are ordered in a linear fashion, and rules are applied in order until one rule either explicitly allows or denies access. No further examination is conducted. If all rules have been found inapplicable, access is denied by a “fall-through exception” rule of least privilege. ■■ Worst fit. All applicable rules are extracted from the rule base and examined against the parameters of the access decision. Access is allowed only if all rules allow access. If no applicable rules are found, or if any rule denies access, then the subject is refused access to the object. ■■ Best fit. All applicable rules are extracted from the rule base and passed to an arbitrator. The arbitrator uses an algorithm based on all parameters and possibly on information external to the parameters of the access decision and priorities between applicable rules to make the best possible decision (which is, of course, application specific). The arbitrator must be consistent. Choosing the right strategy is dependent on application domain knowledge. We recom- mend defining access control rules that satisfy the disjoint property: For any access decision, at most one rule applies. Network appliances that filter packets use this strat- egy. Often, although the access control rules within the appliance work on the first-fit strategy, the architect can ensure that in the design of the policy no further rules will apply. Thus, the configuration of rules on the appliance reflects a uniqueness property. In the following description, we will ignore the dynamic nature of access decision mak- ing, in which either the data or the access control rules can change as we apply our access decision algorithm. In general, access control rules use the following parameters to define an access control rule-base as a function mapping a 4-tuple to the set {ALLOW, DENY}. The fields of the 4-tuple are as follows: ■■ Subject. The active entity, process, user, or system that requests access to a resource. The subject is assumed to have passed some identity and authentication test before requesting service. ■■ Object. The passive target of the access, possibly providing a service, accepting a message, returning a value, or changing state. The object is assumed to have passed some validation test before being made available for access. ■■ Privileged Operation. The type of access requested. For a data object, access could include create, update, delete, insert, append, read, or write modes. ■■ Context. A predicate about the environment that must hold true. Context can catch many environment attributes, such as the following: ■■ Ownership. Did the subject create the object? ■■ History. What sequence of events led to this access request? ■■ Time. Is the time of day relevant? ■■ Quality of service. Has the subject subscribed to some stated level of quality of service that would prevent an otherwise allowed access due to a competing request from higher levels? QoS for business reasons sometimes appears in security solutions. ■■ Rights. Has the subject been granted or revoked certain rights by the system? ■■ Delegation. Does the subject possess credentials from a secondary subject on whose behalf access is being requested? This situation might require a loop back to the beginning to refer to a different rule with all other parameters remaining the same. ■■ Inference. Will permitting access result in a breach in the security policies guidelines for preventing logical inference of information by unauthorized entities? Thus, an access control rule-base defines a function as follows: ACRB : ͳs,o,p,cʹ → {ALLOW,DENY} This function gives us the ability to organize the rules according to different viewpoints. ■■ An access control list is a collection of all access-allowing rules that apply to a single object. For example, an ACL for a file describes all the users who are allowed access and their associated permissions to read, write, or execute the file. ■■ A capability list is a collection of all access-allowing rules that apply to a single subject. For example, based on the security policy, a signed Java applet might be granted access to a collection of system resources normally otherwise blocked by the Java sandbox. ■■ An access mode list is a collection of all access-allowing rules that specify the same mode of access. For example, a corporate directory could specify a permissive security policy with respect to reads, but restrict writes to strongly authenticated administrators only. ARCHITECTURE AND SECURITY 68 Security Architecture Basics 69 ■■ A context list is a collection of all access-allowing rules that share the same context. For example, an application could distinguish between access control definitions during normal operations and those in situations in which the application is responding to a disaster or to a work stoppage by a large pool of users. Applications sometimes abuse the ability to organize by context by exhibiting the inad- visable habit of including business logic into security policy definitions. For example, an application could specify access control rules that restrict, during peak usage, some resource-intensive activities or require all funds transfers to be done before 3 p.m. Monday through Friday because that is when the banks are open. This overlap of func- tionality tends to muddy the distinction between corporate security policy and the operational profile of the system. Understanding the Application’s Access Needs To design a robust model of access control from an architecture perspective, we must first ask ourselves questions about the application domain. RBAC has both flexibility and architectural support for evolution. Creation and Ownership Questions on object creation and ownership include the following: ■■ Do subjects create objects? If so, do we maintain knowledge of an object’s creator within the application? ■■ Do subjects own objects? If so, do we maintain knowledge of an object’s (possibly multiple) owners? Is there a default owner for each object? ■■ Do objects have fine-grained structure? Does access to the object imply access to all parts of the object? ■■ Are objects organized in a hierarchical fashion according to a labeling scheme that honors some security principle? The principle could be: ■■ Secrecy. A subject must have a certain level of clearance to access the object (the Bell-LaPadula model). ■■ Integrity. A subject must have a certain level of trustworthiness to access the object (the Biba model). ■■ Non-repudiation. A subject’s access to an object at one level must be undeniable by a higher standard of proof compared to access to an object at a lower level (this situation does not correspond to a formal model, but non- repudiation protocols consider this factor). ■■ Do objects have non-hierarchical labels that could also be used as context information to make access decisions? Roles and Access Modes Questions on roles and access modes include the following: ■■ Does the application divide its user community into classes of users based on the grouping of user activities into roles in the application’s operational profile? ■■ What access modes do subjects need? Can they create, delete, update, insert, read, write, alter, append, or otherwise modify objects? Does the object need to be protected during each mode of access? Do we audit all object access for forensics? ■■ Does the application assign distinguished status to one member of each role as the member responsible for the integrity of the object? This could be necessary if another user in the role corrupts an object by accident or malice. ■■ Do the access modes of objects within the application have dramatically different structures? This situation occurs if the application has a corporate directory function with wide read access but very restricted write access. If performance requirements are different for different access modes, this might impact the choice of security around each mode (for example, no security for reads to the directory, but writers must be authenticated). Application Structure Questions about structure include the following: ■■ Does the application partition the object space according to some well-defined method? Are objects within each partition invisible to objects in other partitions? Are users aware of the existence of the partitions, or does the application give them the virtual feeling of full access while invisibly implementing access control? ■■ Are any objects contained within a critical section? Will access control to resources in a critical section cause undesirable properties in the system? A critical section within an application is accessible by only using specific atomic requests, which are carefully managed. Critical sections protect resources from corruption or race conditions but can result in deadlock if incorrectly designed and implemented. ■■ Can objects present polyinstantiated interfaces? Polyinstantiation is the ability to create multiple virtual instances of an object based on the credentials of the subject. Access to the actual data, to perform reads or writes, is carefully monitored by coordinating reads and writes to the virtual objects. Users are unaware that they are interacting with polyinstantiated objects. ■■ Does the application contain multiple access control decision points? Is access control implemented at each of the points, and if so, does the chained sequence of decisions comply with the intended security policy? Are all decisions made under a single security policy, or do different information flow points reference different masters for access control decisions? ARCHITECTURE AND SECURITY 70 TEAMFLY Team-Fly ® Security Architecture Basics 71 Discretionary Rules Questions about discretionary access control include the following: ■■ Can users grant privileges to other users? Can users assume the identity of other users legitimately, through delegation? ■■ Can users revoke privileges previously granted to other users? Revocation can cause paradoxes if users are allowed to transitively grant access to other users after they have acquired access themselves. Is revocation implemented in a manner that avoids or detects and corrects paradoxes? ■■ Can objects assume the identity of other objects? ■■ Is delegation allowed? Do we inform the original owner of the object when a downstream delegate accesses it? Obviously, resolving these issues is difficult. We believe, however, that understanding the implications of the architect’s responses to these questions is critical to the design of a correct, consistent, complete, and usable access control solution. The exercise of examining these questions should be accomplished before choosing any vendor prod- uct from several alternatives. Other Core Security Properties We will revisit the other core security properties, such as integrity, availability, confi- dentiality, auditing, and non-repudiation, in the following chapters. Unlike access con- trol, which has a long and rich history of theoretical models, these properties are best discussed with reference to a problem at hand. It is easier to recommend strategies for ensuring these properties within the context of specific application components and technologies. Analyzing a Generic System A generic system or application solves some well-defined problem within a context. The project must build the application around corporate standards and must conform to security policy. Figure 3.3 shows some of the design tensions faced by an architect from an engineering and technology viewpoint. Our example application consists of a Web front end to an application server. The appli- cation server can access legacy applications for data and wrapped business functions and can query a corporate directory for user, group, organization, and system profiles. Infrastructure components for providing services like mail, DNS, time, news, messag- ing, or backup might also need security. SONET/Frame/ATM/IP Satellite dish Comm. Tower Satellite VPN Gateway Partner Firewall Dialup gateway WAP Gateway User's Workstation Laptop Internet Intranet DMZ Partner Application Partner Database Corporate Directory Infrastructure Applications Application Server Application Database Legacy Application Legacy Database Mail, DNS, NID, VPN support, backup, etc. Web Server Networking layout Firewalls and Gateways Communication technologyApplication Architecture Partner interaction User platforms Figure 3.3 Architectural tensions surrounding an application. Around the application, shown in Figure 3.3, are constellations of components that the architect must depend upon, over which he or she might have very little control or choice. ■■ User platforms. Users can access data and services by using a variety of devices including desktops, laptops, pagers, cellular phones, and handheld devices. Each device can support a thin client such as a browser, or a custom-embedded client that must be developed in-house or purchased. The user can communicate with the application with a wide variety of protocols. ■■ Partner applications. The application might have a tight coupling to business partners and require connectivity to a demilitarized zone for secure access to partner data and services. ■■ Networks. A wide variety of logical networks, at varying levels of trust, can carry application traffic. ■■ Firewalls and gateways. Connectivity to the application from each user platform and over each network might require authentication and session validation at one or more gateways. Intermediate firewalls and routers on communications paths might need special configuration. ■■ Communications technology. The application can use several different communications technologies, each supporting security by using a unique paradigm. Other architectural viewpoints also reveal similar collections of artifacts all jostling for attention. Consider a process viewpoint that reorganizes engineering or technology issues on a component basis. Figure 3.4 shows the same example application as it would appear with connections to partners and backend systems, in a generic enterprise. ARCHITECTURE AND SECURITY 72 Security Architecture Basics 73 Web Browser User ID / password authentication Static html and forms for presentation Web Browser Token authentication Dynamic html and forms for presentation Partner Application backend database supports B2B using Web Methods Web Browser X.509 Certificate authentication Java Applet for presentation Servlet Engine JSP, servlet includes Application logic embedded in servlets Static Web Pages Static files, cgi-bin scripts. Dynamic Web Content ND Application server or Web server API to Servet engine Database connectivity management Session Management Load balancing and recovery Error and disaster recovery management Legacy Mainframe CORBA interface to wrapped object implemented with Orbix NetDynamics access to legacy oracle DB Enterprise CORBA distributed object implemented with Visibroker PKI infrastructure from acquisition. Based on RSA Keon Server Infrastructure Services: DNS, Mail WAP Gateway, VPN PKI infrastructure Enterprise vendor is Verisign Oracle Database EJB containers for application logic Figure 3.4 An enterprise application with many components. Thinking about security for the application in the above environment is very difficult, and measuring compliance to policy is even harder. Examine the diagram to see paral- lels or departures from your own application architecture. The remainder of our presentation will explore specific concerns such as writing safe code; trusting downloaded code; securing operating systems, Web servers, and data- bases; and using middleware products securely. We will end by returning to enterprise security as a rallying point for building consensus among systems architects across the corporation. Conclusion The bibliography contains several references for more information about security prin- ciples, properties, authentication mechanisms, and access control. We recommend reading about the history of access control models to better understand the evolution of authorization principles, and the background behind the adoption, by commercial products of several common mechanisms. In the next chapter, we now proceed to our next task: building a catalog of security architecture patterns. T he purpose of security is to enable valid communication, preferably in as transparent a manner as possible. At the same moment, all invalid communication — whether unau- thorized, unauthenticated, unexpected, uninvited, or unwanted — should be blocked. The only way of accomplishing these goals is through authentication of all principals within the application and through inspection of all communication. There are many technologies — each a collection of tools, protocols, and components — all available for designing security solutions to accomplish these two goals. Despite this variety, when we look at the system we can see patterns of implementation emerge at the architec- ture level as a network of components interacting based on the logical relationships imposed by the problem domain. Pattern Goals Our choice of the word patterns might cause some misconceptions because of the con- siderable baggage that the term carries. We thought about alternative terms, such as styles or profiles, but in the end stayed with patterns because, simply, the good out- weighed the bad. Our collection of security patterns shares some of the same goals as the pattern community at large. Specifically, something is a security pattern if: ■■ We can give it a name. ■■ We have observed its design repeated over and over in many security products. ■■ There is a benefit to defining some standard vocabulary dictated by common usage rules to describe the pattern. ■■ There is a good security product that exemplifies the pattern. CHAPTER 75 4 Architecture Patterns in Security Pattern Origins Many of the security patterns that follow have been introduced and discussed in the pattern literature before, albeit not in a security context. We believe all of these concepts are, by their very nature, too well known for any one source to claim original definition. Patterns are, by definition, codified common-sense recognition of solutions to problems within contexts. We will, however, cite references with each pattern when we are aware of a prior description. ■■ There is value in its definition. The pattern might capture expertise or make complex portions of an architecture diagram more intelligible. The pattern might make the evaluation of a product easier by highlighting departures from a standard way of approaching a problem. It might also raise a core set of issues against these departures. We would like to note several important distinctions because of the differences between our pattern descriptions and those of the object-oriented pattern community. ■■ The patterns we describe are not object-oriented in any manner. ■■ We will not use the presentation style commonly used for pattern description. Issues of context, forces, variation, and so on will be described informally when we reach our discussion of specific security scenarios in later chapters. ■■ These patterns do not generate architectural decisions, nor do they provide guidance on how to structure other portions of the system architecture. ■■ They do not codify best practices. Using one of these patterns will not necessarily make your product or system safer. We have a lot of respect for the wonderful contributions of the pattern community and strongly believe in the measurable and quantifiable merits of patterns, both for object reuse and for architecture analysis purposes. We do not want to present the material in the chapter as having virtues beyond that of enabling us to think about security archi- tectures more easily, however. We abstract and present these only so that architects can easily recognize them in designs and then ask good questions about their implementation. We do not intend to start a cottage industry in security pattern definition. Common Terminology There are some terms used by vendors and application developers alike that often reoc- cur in security architecture descriptions. In the following sections, we will describe cer- tain patterns of interaction and label them with a name. This procedure is not an attempt to enforce some abstract nomenclature on an existing and diverse collection of ARCHITECTURE AND SECURITY 76 [...]... the software Architecture Patterns in Security 99 architecture community (see [BBC00]) Layers are common in security architectures, as well A system’s Trusted Computing Base (TCB), defined as a subset of resources that are guaranteed to be safe and can be trusted to execute correctly, is an example of a security layer The layer pattern, shown in Figure 4.8, is one of the most popular architecture artifacts... that each protocol level will work as desired Security architectures use layers to separate security functionality Examples include mechanisms for secure transport such as SSL, mechanisms for secure infrastructure such as PKI, and security services such as virus scanning within e-mail applications Layered architectures are often strict; layered security architectures are even more so Strict layering... the security architecture principles The principles are guaranteed to hold Many products describe their environments as a sandbox with varying degrees of success ■ ■ The Java sandbox has a well thought-out but complex security architecture Initial implementations of the sandbox were found to have security holes, which have been patched We will defer our discussion of security policy management, the security. .. within an architecture viewpoint that looks at object, process, or business perspectives Although tcpwrapper does an excellent job of securing network access to a single host, a security architect has additional concerns What if hosts are clustered, objects are distributed over the network, Architecture Patterns in Security 93 or access definitions vary in application-specific ways, from architecture. . .Architecture Patterns in Security 77 security artifacts We will continue to describe any and all security features in the words and terminology of their creators, but we will use the patterns described in this chapter as the starting point for a taxonomy for describing security options available in particular parts of the systems architecture: within code, within the... Access decisions, once made and approved, can be recorded to tokens, and circulated to other components in the architecture This process can simplify decision making when complex arbitration, involving the history of the principal’s actions, is required Architecture Patterns in Security 83 In a nonsecurity-related context, token ring networks share resources through managing possession of a token The token... wrapper For an overview of security wrappers, please see [GS96a] Team-Fly® Architecture Patterns in Security 91 Filter Filters are the first of three man-in-the-middle security components of the channel elements section—the others being interceptors and proxies Filters were also defined in the Gang of Four book [GHJV95] under the label Bridge and in [POSA1] as a software architecture pattern called... session layer into the protocol For example, CORBA security solutions secure IIOP over TCP/IP, adding an application level security layer by running IIOP over SSL over TCP/IP Alternatively, hardware encryption units that implement encrypted Ethernet LANs add communications security at the other extreme The elevator pattern is commonly seen in layered architectures, where strict layering is desired, but... they be replaced in a timely fashion? TE AM FL Y 80 The first step in any security architecture is the identification and classification of all participating principals Team-Fly® Architecture Patterns in Security 81 Context Holders Context holders contain context attributes that add to our knowledge of the principal during a security access decision, within a session, on a resource request Session... configured to accept secure connections only, not all daemons can be secured using the currently available security solutions The security holes in the underlying hosts and the lack of integration with security infrastructures all make for a messy and insecure environment Please refer to Chapter 9, “Middleware Security, ” for more details ■ ■ Many commercial products exist to protect a host from (possibly untrusted) . could specify a permissive security policy with respect to reads, but restrict writes to strongly authenticated administrators only. ARCHITECTURE AND SECURITY 68 Security Architecture Basics 69 ■■ A. technologyApplication Architecture Partner interaction User platforms Figure 3. 3 Architectural tensions surrounding an application. Around the application, shown in Figure 3. 3, are constellations. basis. Figure 3. 4 shows the same example application as it would appear with connections to partners and backend systems, in a generic enterprise. ARCHITECTURE AND SECURITY 72 Security Architecture