Security Architecture For Business Applications
July 7, 2015 Patrick Botz
|
Developers can make it infinitely less complex to manage the security of a system and can significantly improve the security of any computer system by following a simple architecture in their applications. Conversely, not following a similar architecture makes it virtually impossible for any administrator to both maintain the best security possible and avoid failed and crashed applications. Nearly everyone in most IT shops assumes that it is the system (or security) administrator’s responsibility to manage access control for the data on the system. They also assume it is the administrator’s responsibility to fix any authority failure issues encountered by users. But when you think about this, it doesn’t really make sense for administrators to have this responsibility. Who knows more about which data an application uses and how and where within the application it gets used? I assert that few administrators have this kind of knowledge about the internals of any application. Thus, when encountered with an authority failure, they usually “fix” the problem by ensuring that nobody will ever encounter that same failure again. How? By making sure that everyone has the ability to create, read, change, and delete that data or file . . . by default! This, of course, makes it much easier for an attacker to access that data. But this can be avoided pretty easily without anyone–developers or administrators–having to manage access control for specific users while at the same time ensuring that others using the system but not running the application can’t access the application’s data. This scenario is the cheapest to manage, but it requires that applications be written with a certain set of assumptions that lead to a general security architecture. The assumptions developers should use when architecting any new application or program are:
Using these assumptions when architecting and implementing an application makes it easier and faster to deploy the application from a security perspective, and makes it much easier and cheaper to manage access control and avoid authority failures over time. If an administrator can assume that the application controls that users are allowed to perform which business functions, then administrators only need to manage which users can use the initial program associated with the application. This makes it very easy to create a group for authorized application users. Add each user authorized to use that application to the group and then grant that group read or use authority to the initial program. Many business applications are architected with some sort of “business function and authorized users” table that the application uses to control which users are allowed to access which business functions, so that doesn’t represent any new or extra work on behalf of developers. All operating systems support mechanisms and APIs that allow programs to manipulate the authority under which they are executing at the time the program is built and even during execution. Programmers know what data objects they are accessing and what authority the program will need to be running under when it accesses those objects, so programmers can use the most appropriate API to ensure that the program has the required authority to the data at the time it accesses the data. This represents extra work for developers, but just is one time and extremely small (especially when compared to the effort required for an administrator to identify all of the data objects, determine what authority each user may need to those objects, and then attempt to manage that access control over time). I recently wrote an article for IBM Systems Magazine‘s AIXExtra newsletter that goes into more technical detail about the mechanisms and APIs available on AIX and IBM i–adopted authority and the user profile “swap” APIs being just two of them–developers can use to implement this security architecture. You can find it here. By exploiting these tools, developers can ensure their applications will not fail due to authority failures while administrators can focus only on controlling access for users allowed to run those applications. Patrick Botz is President and CTO of Botz & Associates. His expertise includes security strategy, security policy enforcement, password management, single sign-on (SSO), industry and government compliance, and biometrics. He is the architect of the SSO stat! service. Previously he worked as Lead Security Architect at IBM, and he founded the IBM Lab Services security consulting team. You can connect with Pat here. RELATED STORIES Security Policies Vs. Security Procedures Job User Name And Current Job User
|
