Identity and access management (IAM) refers to a framework of policies, technologies, and techniques to control identities in an electronic system. IAM frameworks allow administrators to control who can access each digital resource in an organization and what actions they can take.
Organizations often implement a multi-layered IAM architecture to manage user access privileges based on roles or identity-based policies. Ideally, access policies should ensure that users only have the permissions they need to do their jobs, preventing individuals from viewing sensitive data or performing risky actions. The IAM system helps enforce these policies.
IAM is not a single solution you can simply purchase and deploy out of the box. It is a collection of technical components, processes, and practices.
An enterprise IAM architecture includes multiple layers of services and processes. At its heart is a directory service such as Lightweight Directory Access Protocol (LDAP) or Active Directory, which acts as a repository for the organization’s user identities, credentials, and attributes. Some organizations have more than one user directory, representing different units or organizations within the enterprise.
The directory service interacts with other IAM components that define processes like authentication, user management, provisioning, and access federation. Here are the main categories of IAM processes in a large organization:
Related content: Read our guide to IAM framework (coming soon)
To understand how IAM systems are evolving in the cloud era, let’s review the Open Security Architecture (OSA) design pattern for IAM, known as SP-010. This is the OSA diagram illustrating the SP-010 pattern.
This architecture represents the way IAM worked when most organizational resources were deployed in an on-premise data center.
Here are a few discrepancies between this diagram and the way organizations do IAM today:
Here are some best practices to help ensure an effective IAM architecture.
IAM frameworks often have users with multiple identifiers, which can apply to internal and external users (i.e., staff and customers). A public identifier provides access to both types of users, usually limited to non-confidential data such as usernames, phone numbers, and email addresses. Users can change their public identifiers.
A private identifier can apply to an external user, but only internal admins can change it. Private identifiers are often part of multi-factor authorization, adding a layer of protection. They contain confidential information such as biometric data and are not visible to public users.
To ensure security, personally identifiable information (PII) should remain separate from other data. PII includes any information used to trace individuals, such as names, birthdates, social security numbers, and personal records. PII breaches result in compliance violations, often with significant legal consequences for companies that fail to protect their data.
PII should have dedicated, private storage regardless of the storage model.
Access controls are effective only if users understand them. Externalizing the access control rules makes them easier to understand and follow. This approach helps make IAM implementation simpler. The IAM system should consider how it will enforce the access control rules—various policy models can determine IAM rule enforcement.
An experienced IAM architect knows the technical language required to write effective access control rules and enforcement policies.
Each network component should have a suitable trust level. Separating components in this way restricts access between them, providing added protection against hackers. Organizations should consider assigning the following trust levels to their network:
While building an IAM architecture, each component should have a different trust level. For instance, the identity provider might have the highest trust level.
Pseudonymization helps protect private and public identifiers by masking their true values while enabling sharing across systems. For example, an organization might assign employees regularly changing pseudonyms to mask their private identifiers.
Organizations can also apply pseudonyms to service providers, allowing users to change their public identifiers without causing disruptions.
Encryption helps protect data during storage and transit—essential for an IAM system. While data protection standards restrict sending sensitive data over an unsecured network, hackers might still be able to access it. Certain industries require companies to encrypt data in transit but neglect vulnerabilities at rest. Organizations should encrypt all confidential data at every stage, not just during active use.
The Pathlock Security Platform builds on existing Role-Based Access Controls (RBAC) to create a security layer based on the context of access, such as time, device, location, IP address, etc. Using Attribute-Based Access Control (ABAC), Pathlock allows you to restrict and/or mask user access to sensitive data at the page and field level inside your ERP applications. This gives security teams the controls they need to determine risk and mitigate it across ERP applications.
Pathlock also allows you to implement layered security controls within your ERP applications. The platform’s ability to mask data at the field level shields sensitive PII data like Social Security Numbers, bank account details, etc. While the Click-to-View feature allows users to view data when needed, it also creates an access log that helps security teams detect suspicious user activity. Additionally, Pathlock enables you to implement in-line authentication challenges to perform sensitive transactions. Moreover, these features also provide a reliable audit trail and enhance compliance.
Schedule a demo with our security experts to find out how Pathlock’s adaptive security enhances data security and compliance within your ERP applications.
Share