Blog & News

Over the past decade, Enterprise Architecture team at AceNet has performed various roles as a Solution and Enterprise Architect across organizations of all sizes; from startups and SMEs to regional corporates and global enterprises. Across this diverse landscape, one theme has remained consistent: while technological solutions evolve, security remains a constant and critical concern.

An Enterprise Architect (EA) has the unenviable yet essential responsibility of not only understanding technology at scale but also ensuring that every solution is fundamentally aligned with security principles. This does not mean being a specialist in the security domain but rather possessing a solid awareness of key security checkpoints; enough to guide, assess, and validate designs ensuring that enterprise assets are protected from cyber threats.

Today, the role of the EA extends far beyond governance and oversight. It requires active partnership with project teams; validating solution proposals across multiple architecture views, including process, deployment, integration, and data. Yet one of the recurring gaps we have observed is in cybersecurity. Often, project teams lack sufficient awareness or omit critical security aspects during solution design. These gaps, if unchecked, become serious risks to enterprise assets.

To address this, the EA team at AceNet has collaboratively developed the Security Architecture Review Guidelines, a practical checklist aimed at covering common security compliance considerations for enterprise technology solutions. While not every item will apply to every project, the expectation is that each relevant security aspect is explicitly addressed as part of the Solution Architecture - Security View. This guideline is especially designed for global and regional enterprises with a formal EA governance structure. It focuses on common security scenarios in typical enterprise web or mobile application solutions; whether they are built for employees, customers, partners, or other external entities associated with the business.

Our goal is simple: to make security an integrated, proactive, and non-negotiable part of the architectural conversation. By doing so, we not only enhance solution integrity but also reinforce enterprise resilience in an increasingly digital world.

Identity and Access Management (IAM)

In any regional or global enterprise, identity management is a foundational security component. Organizations typically operate centralized identity platforms such as Microsoft Active Directory (on-prem), or leverage cloud-based identity providers like Microsoft Entra, Google, or Apple for authentication and user lifecycle management; serving both employees and, in some cases, customers. All SaaS and custom in-house applications must integrate with the corporate identity provider to ensure a unified and secure authentication experience through single sign-on (SSO). These integrations should strictly follow the enterprise-standard authentication protocols, that must include Multi-Factor Authentication (MFA) to mitigate the risk of credential-based attacks.

As enterprises continue to expand through acquisitions, mergers, and strategic supplier partnerships, many are adopting federated identity models. This allows secure cross-organizational access while preserving each entity’s brand identity and operational autonomy. Federated authentication still requires adherence to enterprise security standards, including mandatory MFA.

In all cases, MFA using approved methods such as, Okta Verify, Microsoft Authenticator, Google Authenticator, or equivalent; should be implemented across all enterprise applications.

Once a user has been authenticated, authorization determines what resources they can access and what actions they can perform. This is often managed through role-based access control (RBAC) or attribute-based access control (ABAC). Most business applications support multiple user roles to control access to various business capabilities. RBAC is a foundational requirement for enforcing secure and appropriate access to application features and data.

In a typical n-tier, service-oriented architecture, RBAC must be implemented consistently across all layers of the application stack:

• User Interface Layer: UI components must dynamically adjust visibility and access to features based on the user’s role to prevent unauthorized actions.
• API / Microservices Layer: Each API or service must validate the user’s permissions independently to enforce backend-level access control, even if the UI has already restricted certain actions. Delegated identity of the logged-in user should be passed through to back-end services, enabling granular, user-level access control. In some scenarios, a service identity may be used, but delegated user identity is preferred for traceability, accountability, and least-privilege enforcement.
• Storage/Data Layer: Where supported by the database technology, RBAC can be implemented at the data level using:
  
  • Row-level or column-level security to restrict data visibility based on the user's role or identity.
  • Table- or document-level permissions to limit access to entire datasets.

Integration Security

In most enterprises, a standardized Enterprise Service Bus (ESB) solution is used to orchestrate and secure integrations across internal and external systems. These platforms provide centralized governance, monitoring, and enforcement of security policies for all integration flows. Where such a standard ESB exists, all solution integrations must be routed through the ESB to ensure alignment with enterprise-wide security and compliance standards. The ESB acts as a secure, policy-enforcing intermediary that supports transformation, throttling, auditing, authentication, and encryption.

In cases where an ESB has not been adopted, point-to-point integrations may be implemented, though this is considered less than ideal. As the number of integration points increases, there is an exponential increase in risks; such as inconsistent security enforcement, increased surface area for attacks, and greater maintenance overhead.

For such point-to-point or direct API integrations secure trust mechanisms must be implemented, such as:

• JWT tokens
• OAuth 2.0 / OpenID Connect
• Mutual TLS (mTLS)
• API Keys (least secure; to be used only when other methods are not feasible, and must be rotated and access-controlled)

Integration security must also consider:

• Whether the systems are internal or external to the enterprise network
• Data sensitivity and compliance requirements (e.g., PII, financial data)
• Logging, audit, and error-handling standards

Data Security

Data is one of the most critical assets of any enterprise, and its security must be addressed holistically; covering both logical and physical layers of the security architecture. Effective data security design covers data classification, access control, secure storage, and secure transmission, while also meeting regulatory compliance obligations.

Logical Security Controls

• Data Classification: Data should be classified (e.g., Public, Internal, Confidential, PII, Regulated) to determine the appropriate security measures.
• Access Control: User access rights must be enforced at logical layers (application, API, database queries) using principles of least privilege and role-based access control (RBAC).
• Masked Views for Support Teams: Applications must provide specialized support views where PII is masked or excluded to ensure that operational staff can perform duties without accessing sensitive personal information.

Physical Security & Data at Rest

• Encryption: All sensitive data; regardless of the storage technology used (e.g., RDBMS, NoSQL, Object Storage, Time Series, Graph Databases)—must be encrypted at rest.
• Key Management: Client-managed keys (CMKs) are preferred for stricter control and compliance, especially in regulated industries.
• Data Masking in Non-Production Environments: Encryption may be optional in Dev, Test, QA environments; however, if production data is used, it must be masked or anonymized prior to import.

Data in Transit

Transmission Security: All data transferred between services, systems, or third parties must be secured using TLS (HTTPS) or stronger transport-layer encryption protocols.

Regulatory Compliance

• Ensure that the data security strategy addresses applicable regulatory frameworks such as: GDPR, HIPAA, PCI-DSS, CCPA, or industry-specific regulations.
• Both logical and physical security controls must be auditable and documented for compliance readiness.

Mobile Application Security

Mobile applications must adhere to specific security requirements beyond general application standards. The following guidelines should be observed:

Authentication and Authorization:

All mobile applications must implement authentication and authorization mechanisms in compliance with the organization's established standards and security protocols.

Local Data Storage:

Any sensitive data stored locally on the device must be encrypted using industry-standard encryption algorithms to prevent unauthorized access.

Employee-Facing Applications:

For enterprise or employee-facing mobile apps, organizations may enforce Mobile Device Management (MDM) policies, which can include:

• Biometric-based authentication for secure access.
• Enforcement of app usage restrictions.
• Remote wipe capabilities in case of device loss or theft to protect corporate data.

Secure Development Lifecycle Practices

Security must be integrated into the early stages of the software development and testing lifecycle to proactively address design-level vulnerabilities such as SQL Injection, Cross-Site Scripting (XSS), and other common attack vectors.

Key best practices include:

Secure Coding and Early Testing:

Implement secure coding principles from the beginning of the development process. Integrate security-focused testing during design, development, and QA stages to catch vulnerabilities early to significantly reduce security risk exposure and build more resilient applications.

Automated Security Scanning:

Incorporate security checks within the CI/CD pipelines using tools like SonarQube, Checkmarx, or equivalent. These tools help detect code quality issues and security risks automatically, enabling developers to remediate issues before they reach production.

Open-Source Dependency Management:

Modern applications often rely heavily on open-source libraries. To mitigate associated risks:

• Maintain an up-to-date inventory of all third-party components.
• Regularly monitor for known vulnerabilities.
• Schedule regular updates and patch cycles to apply security fixes as new versions are released.

Perimeter Security Control

A strong perimeter defence is critical to securing an organization’s internal network from external threats. Modern enterprises employ a layered approach using multiple technologies to detect, prevent, and respond to security incidents, a concept known as defence in depth. This approach ensures that if one line of defence is compromised, additional layers exist to stop threats.

Firewall:

The firewall is the first line of defence, acting as a barrier between trusted internal networks and untrusted external networks (e.g., the internet). It enforces security rules to allow or block network traffic based on IP addresses, ports, protocols, and defined security policies.

Intrusion Detection System (IDS):

IDS solutions monitor network traffic for suspicious behaviour or known attack patterns. When a potential threat is detected, alerts are generated to notify security teams, enabling timely investigation and response.

Intrusion Prevention System (IPS):

IPS builds upon IDS by not only detecting suspicious activity but also actively blocking malicious traffic in real-time, thereby helping to prevent attacks before they cause harm.

Web Application Firewall (WAF):

The WAF is specifically designed to protect web applications by filtering, monitoring, and blocking HTTP/HTTPS traffic. It defends against common application-layer attacks such as SQL injection, Cross-Site Scripting (XSS), and other OWASP Top 10 threats.

Hope this has been insightful, look out for a detailed EA security checklist in our upcoming blog soon.