i Attacking application architecture – Securing Tiered – All things in moderation

Attacking application architecture – Securing Tiered

In previous post I introduced about Tiered architecture . And now I’ll present about Securing tiered architecture .
If carefully implemented, a multitiered architecture can considerably enhance an application’s security, because it localizes the impact of a successful attack. In the basic LAMP configuration described previously, in which all components run on a single computer, the compromise of any tier is likely to lead to complete compromise of the application. In a more secure architecture, the compromise of one tier may result in partial control over an application’s data and processing, but it may be more limited in its impact and perhaps contained to the affected tier.

Minimize Trust Relationships

As far as possible, each tier should implement its own controls to defend against unauthorized actions and should not trust other application components to prevent security breaches that the tier ifself can help block. Here are some examples of this principle being applied to different tiers of the application:
* The application server tier can enforce role-based access control over specific resources and URL paths. For example, the application server can verify that any request for the /admin path was received from an administrative user.
* The database server tier can provide various accounts for use by the application for different users and different actions.. For example, actions on behalf of unauthenticated users can be carried out with a low-privileged account allowing read-only access to a restricted set of data
* All application components can run using operating system accounts that possess the least level of privileges required for normal operation.This mitigates the impact of any command injection or fi e access flaws within these components. In a well-designed and fully hardened architecture, vulnerabilities of this kind may provide an attacker with no useful opportunities to access sensitive data or perform unauthorized actions

Segregate Different Components

As far as possible, each tier should be segregated from interacting with other tiers in unintended ways. Implementing this objective effectively may in some cases require different components to run on different physical hosts. Here are some examples of this principle being applied:
* Different tiers should not have read- or write-access to files used by other tiers. For example, the application tier should not have any access to the physical fi les used to store database data, and should only be able to access this data in the intended manner using database queries with an appropriate user account
* Network-level access between different infrastructure components should be fi ltered to permit only services with which different application tiers are intended to communicate.

Apply Defense in Depth

Depending on the exact technologies in use, a variety of other protections can be implemented within different components of the architecture to support the objective of localizing the impact of a successful attack. Here are some examples of these controls:
* All layers of the technology stack on every host should be security hardened, in terms of both confi guration and vulnerability patching.
* Sensitive data persisted in any tier of the application should be encrypted
to prevent easy disclosure in the event that that tier is compromised.

Leave a Reply