Design principles for architectural security
Security is all about the ability to protect your system and information while delivering business value for your customers. Lack of good security can have a serious impact on your customers and business.
You need to conduct an in-depth security risk assessment and plan a mitigation strategy for the continuous operation of your business. The following sections talk about standard design principles that will help you strengthen your architectural security.
Implementing authentication and authorization control
The purpose of authentication is to determine whether a user can access the system with the provided credentials, while authorization determines what a user can do once they are inside the system.
You should create a centralized system to manage your users’ authentication and authorization. A centralized user management system helps you to keep track of users’ activity so you can deactivate them if they are no longer a part of the system or are no longer using it appropriately. You can define standard rules to onboard a new user and remove access for inactive users. A centralized system eliminates reliance on long-term credentials and allows you to configure other security methods, such as password rotation.
For authorization, you should start with the principle of least privilege—this means users should not have any access to begin with and are assigned only the required access types according to their job role. Creating an access group according to job role helps to manage the authorization policy in one place and apply authorization restrictions across a large number of users. For example, you can restrict the development team to have full access to the development environment and read-only access to the production environment. If any new developer joins, they should be added to this dev group, where all authorization policies are managed centrally.
Enabling single sign-on (SSO) with a centralized user repository helps to reduce the hassle of remembering multiple passwords for your user base and eliminates any risk of password leakage. To further enhance security, integrating multi-factor authentication (MFA) with SSO adds an additional layer of protection. MFA requires users to provide two or more verification factors to gain access to a resource, such as a security token, a fingerprint, or facial recognition.
Large organizations use centralized user management tools such as Active Directory (AD) for employee authentication and authorization to provide access to internal enterprise applications such as the HR system, the expense system, and the timesheet application.
In a customer-facing application, such as e-commerce and social media websites, you can use an OpenID authentication system to maintain a centralized system. OpenID is an open standard authentication protocol. You will learn about large-scale user management tools in more detail in the OAuth and OpenID Connect section of this chapter.
Applying security everywhere
Often, organizations primarily focus on ensuring the physical safety of their data center and protecting the outer networking layer from any attack. Instead of just focusing on a single outer layer, ensure that security is applied at every application layer.
Apply the defense-in-depth (DiD) approach to layer security controls throughout an application; for example, a web application needs to be secured from external internet traffic by protecting the Enhanced Data rates for Global Evolution (EDGE) network and Domain Name System (DNS) routing. Apply security at the load balancer and network layers to block malicious traffic.
Secure every application instance by allowing only required incoming and outgoing traffic in the web application and database layer. Protect operating systems with antivirus software to safeguard against any malware attack. Apply both proactive and reactive measures of protection by putting an intrusion detection system (IDS) and intrusion prevention system (IPS) in front of your traffic flow and using a web application firewall (WAF) to protect your application from various kinds of attacks. You will learn more details about the various security tools to use in the Selecting technology for architectural security section of this chapter.
Reducing the blast radius
While applying security measures at every layer, you should keep your system isolated in a small pocket to reduce the blast radius. If attackers get access to one part of the system, you should be able to limit a security breach to the smallest possible area of the application. For example, in a web application, keep your load balancer in a separate network from other layers of the architecture, as that will be internet-facing. Further more, apply network separation at the web, application, and database layers. If an attack happens in one layer, you should prevent it from expanding to other layers of the architecture.
The same rules are applied to your authorization system, giving the least privilege to users and providing only the minimum required access. Implement MFA so that even if there’s a breach in user access, the attacker always needs a second level of authentication to get into the system.
Provide minimal access to the system to ensure that you are not exposing the entire system, and provide temporary credentials to make sure access is kept open for a short time. Take precautions when providing programmatic access by putting a secure token in place with frequent key rotation.
Monitoring and auditing everything all the time
You need a logging mechanism for every activity in your system, and you should conduct a regular audit. Audit capabilities are often required from various industry-compliance regulations. Collect logs from every component, including all transactions and each API call, to put centralized monitoring in place. It is a good practice to add a level of security and access limitations to a centralized logging account so that no one can tamper with it.
Take a proactive approach and be ready to handle any incident before the user is affected. Alert capabilities with centralized monitoring help you take quick action and mitigate any incident. Monitor all user activity and application accounts to limit a security breach.
Automating everything
Automation is essential for applying quick mitigation for any security-rule violation. You can use automation to revert changes against desired configurations and alert the security team—for example, if someone added admin users to your system and an open firewall to an unauthorized port or IP address. You can apply automation to remove such undesired changes in the system.
Applying automation to security systems has become popular with the concept of DevSecOps. DevSecOps is about adding security to every part of application development and operations. You will learn more about DevSecOps in Chapter 11, DevOps and Solution Architecture Framework.
Create secure architectures and implement security controls that are defined and managed as code. You can version-control your security as a code template and analyze changes as required. Automated security mechanisms as software code help you scale security operations more rapidly and cost-effectively.
Protecting data
Data is at the center of your architecture, and it is essential to secure and protect it. Most of the compliance regulations in place are there to protect customer data and identity. Most attacks have the intention of stealing user data.
You should categorize your data by its sensitivity level and protect it accordingly. For example, customer credit card information should be the most sensitive data and should be handled with the utmost care. On the other hand, a customer’s first name may not be that sensitive, while the card number is sensitive information.
Protecting data throughout its lifecycle is crucial for maintaining its confidentiality, integrity, and availability. Data can exist in three states, and each state requires specific security measures to ensure comprehensive protection:
- Data at rest: This refers to data stored on physical media, whether on a server’s hard drive, a laptop, a USB stick, or cloud storage. One protection mechanism for data at rest is encryption, which ensures that even if the storage device falls into the wrong hands, the data remains inaccessible without the encryption key. Additionally, you need to have access controls and regular audits in place to ensure that only authorized users can access or modify the data.
- Data in transit: When data moves across a network—from a user’s computer to a server, between servers, or across the internet—it’s considered in transit. To protect data in transit, you can use encryption protocols such as Transport Layer Security (TLS). This ensures that even if the data is intercepted during transmission, it remains unreadable to the attacker.
- Data in use: This is often the most challenging state to protect because the data is being processed or used by applications. Encryption can protect data at rest and in transit, but once it’s loaded into memory and being used by an application, it’s in plaintext and potentially vulnerable. New technologies such as trusted execution environments (TEEs) and homomorphic encryption are emerging to secure data in use, allowing operations on encrypted data without needing to decrypt it first.
Create mechanisms and tools that minimize the need for direct access to data. Avoid manual data processing by applying tool-based automation that eliminates human error, especially when handling sensitive data. Apply access restrictions to the data wherever possible to reduce the risk of data loss or data modification.
Once you categorize data by sensitivity, you can use the appropriate encryption, tokenization, and access control to protect the data. Data needs to be protected not only at rest but also in motion—when being transmitted over the network—as well. You will learn about various mechanisms to protect data in the Data security section of this chapter.
Responding to security incidents
Keep yourself ready for any security events. Create an incident management process as per your organizational policy requirements. Incident management can differ from one organization to another and from one application to another. For example, if your application handles the personally identifiable information (PII) of your customers, you need tighter security measures in your incident response. However, if the application is handling small amounts of sensitive data, such as an inventory management application, then it will have a different approach.
Make sure to simulate the incident response to see how your security team would recover from a situation.
Your team should use automation tools to speed up detection, investigation, and response to any security event. You will need to set up the alert, monitor, and audit mechanisms to do root cause analysis (RCA) to prevent such events from occurring again.
In this section, you learned about the general security principles to apply in your architecture for application security. In the next section, you will learn how to apply these principles using different tools and techniques.