Access Rights and Access Controls in the System/Application Domain
The System/Application Domain is perhaps the most protected domain in relation to users. Both local and remote users must pass through several domains to access any components in the System/Application Domain. That means it is reasonable to expect users and attackers to have already encountered several layers of security controls to make it this far. Recall that a good security plan involves several layers of controls. You should deploy solid controls that protect each domain. However, it isn’t good enough to rely on security controls in other domains. Although it is reasonable to expect the System/Application Domain components to be relatively safer than Internet-facing components, you still must protect all components in each domain.
System Account and Service Accounts
The systems and service accounts are different. They are nonhuman accounts that are used to support the system and applications. Because applications can be coded to refer to either of these types of accounts, for discussion purposes we will define both accounts but focus on service accounts within applications.
A system account is a user account that is created by an operating system during its installation, such as the root account on Linux or administrator account on Windows. Developers should not code system accounts into the application logic. System accounts are generally highly privileged accounts.
A service account is a nonhuman account. Ideally, these accounts should be configured as noninteractive accounts, meaning a user cannot sign into these accounts. They can only function when coded in an application or system.
The distinction between system accounts and service accounts can be blurred as system accounts are sometimes used to run operating system services. Often an application will need to access data and other services on behalf of the user. In these instances, a service account (sometimes referred to as an “application account”) can be used. For example, an application can use a service account to access data from a database on behalf of the user. This may simplify the coding while putting accountability for access management within the application.
Following the path, it is easy to see that an attacker can get right to your web server in the DMZ. To make your distributed application available to the maximum number of people, your firewalls will likely leave your web server ports wide open. All an attacker has to do is compromise your web server to potentially connect right to your application server. One well-placed attack can threaten your System/Application Domain. That’s why having layered security controls in every domain is essential.
Your System/Application Domain should implement access controls for nodes and users. You should use Network Access Control (NAC) software, such as PacketFence or Sophos NAC Advanced, with positive authentication to ensure no rogue nodes are allowed to access System/Application Domain components. To address attacks from your web server, your application server should enforce user access controls. In addition, your application should enforce its own user access controls. You should define one set of users for remote access through a web server and another set of users for internal access. That way, you can separate the rights and permissions and also audit remote user access more aggressively. The most secure position is to assume all access requests are potentially hostile and then evaluate each one with aggressive access controls.