Best Practices for Augmenting IDaaS in a Cloud IAM Architecture PAM DINGLE, PING IDENTITY OFFICE OF THE CTO

Transcription

1 Best Practices for Augmenting IDaaS in a Cloud IAM Architecture PAM DINGLE, PING IDENTITY OFFICE OF THE CTO W HI T E P A P ER

2 TABLE OF CONTENTS 03 EXECUTIVE OVERVIEW 04 BEST PRACTICE #1: IMPLEMENT ADMINISTRATIVE SINGLE SIGN-ON (SSO) 05 BEST PRACTICE #2: SUPPORT CHANNELING MULTIPLE IDENTITY SOURCES 07 BEST PRACTICE #3: ADD FACTORS TO PASSWORD SIGN-ON 08 CONCLUSION 2

3 EXECUTIVE SUMMARY Enterprises are embracing cloud and mobile technologies. As they do, they re moving beyond traditional network boundaries and the capabilities of their legacy identity and access management (IAM) solutions. As a result, identity as a service (IDaaS) has become a viable technology for many organizations. Basic IDaaS providers typically focus on SSO for software-as-a-service (SaaS) applications. However, most large enterprises have sophisticated environments and must coordinate and secure multiple resource domains, representing a hybrid mix of on-premises, infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and SaaS resources, which belong to your organization, partners and even social networks. This white paper describes how enterprise IDaaS harmonizes all the loosely coupled elements in the digital enterprise to contribute to better security and mitigate risk for the overall platform. It describes the IAM best practices your organization should consider when securing the digital enterprise. THE ROLE OF IAM IN SECURING THE DIGITAL ENTERPRISE IAM plays a vital role in the digital enterprise in coordinating and integrating resource domains. Whether it s creation of an authentication ceremony, definition and enforcement of policy, enforcement of those policies at APIs or code samples for mobile app writers, the requirements necessary to perform true IAM in the cloud still encompass numerous software and service entities, across numerous domains. Most enterprises of any reasonable size are subject to a wide variety of regulations, and have a collection of legacy and modern systems in place, such as applications, business processes and data stores. They don t have the luxury of starting fresh and only using purpose-built Saas applications for everything. Additionally, local and international regulations can pose restrictions and challenges on the type of information being stored and where it can be stored. As opposed to basic IDaaS, enterprise IDaaS takes a more holistic approach to solve this challenge. Enterprise IDaaS enables the preservation of existing IAM investments, a concentric security and policy model and a shared approach to risk. When adopting enterprise IDaaS to secure the digital enterprise, there are some best practices to consider: 1. Implement administrative SSO 2. Support channeling for multiple identity sources 3. Add factors to password sign-on 3

4 BEST PRACTICE #1: IMPLEMENT ADMINISTRATIVE SSO The best benefit of an SSO architecture is that passwords are stored in a single, well-watched and protected space where central policy is applied. Compare this to application silos across multiple domains, which all support different password and authorization policies, and store passwords that may all be the same (for example, end users who reuse passwords rather than choosing unique ones). The same problem exists with administration accounts, but the stakes are higher. An enterprise IDaaS platform should allow you to link administrative accounts to a federated source. Without such a feature, administrative users must separately manage passwords for isolated accounts outside of a common policy domain. These accounts are often unused and unmonitored, and they represent valuable targets for attackers. Given the power of such accounts, this oversight is important to recognize and to plan to mitigate. POLICIES FOR ADMINISTRATOR SSO All administrators should use their normal everyday sign-on credentials to manage the administrative consoles of an enterprise IDaaS. As a result, authorized end users essentially open an application to access administrative consoles. The ability to access an administration console no longer becomes a question of who has a username and password, but who is authorized by policy. This means that organizations no longer need to worry about exiting administrators retaining credentials for remote infrastructure. In addition, it becomes difficult to share administrator accounts, making the accountability of the logged activities of each administrator stronger. A second benefit to using federation to access these administration consoles is redundant audit. For every administrator authentication at the remote site, two separate pieces of infrastructure are writing audit logs: the federation server acting as the identity provider (IdP), and the federation server acting as the relying party (RP). This gives the organization the option to compare the audit trails of both entities, and to detect anomalies that could indicate compromise, such as an administrator sign-on at the RP when no sign-on occurred at the IdP. Enterprises should consider feeding audit output from every domain they interact with into a Security Information Event Management (SIEM) tool, which can help flag inconsistent behavior. PUBLIC IDAAS IDENTITY BRIDGE AUDIT DOMAIN BREAK-GLASS ADMIN ACCOUNT ADMINISTRATOR ACTIVITY AUDIT 4

5 POLICIES FOR ADMINISTRATOR BREAK-GLASS ACCOUNTS Password-protected accounts that can t be replaced with SSO become dangerous liabilities for organizations, and need to be strictly managed by process rather than by technology and policy. The most common account that falls into this category is the primary administration account for a service. Every service must offer a primary administration account outside of SSO it s necessary in case SSO fails. This primary account should not be used for day-to-day administration of the service, but should instead only be used when absolutely necessary. The password associated with this account should be randomly generated and placed into some kind of vault (for example, a Privileged Access Management system) that has strong controls over release of the credential that can t be bypassed by any single administrator. Lastly, any retrieval of credentials to that account or use of that account should result in instant red flags, requiring investigation and justification. For critical infrastructure access where emergency account access is required, a multi-party process may be needed to retrieve break-glass credentials (think of a nuclear launch code that requires multiple keys to be simultaneously turned). THE ROLE OF AUDIT PROCEDURES Immutable audit is an additional consideration for administrator SSO. Often, no account is created for administrators who SSO to cloud administrator consoles. It s critical to monitor and review the list of users who access administrative consoles over time. Real-time notifications that are broadcast to multiple sources at the time of administrator access make it difficult for a single rogue actor to erase actions after the fact. At the end of the day, this best practice is intended to make sure that standalone administrator accounts are never forgotten or abused. BEST PRACTICE #2: SUPPORT CHANNELING FOR MULTIPLE IDENTITY SOURCES Within complex organizations, users come from many places. Some users may be employees, coming from an on-premises or IaaS resource domain such as UnBoundID, Active Directory or Azure AD. Others may be contractors, coming from a PaaS or SaaS identity repository such as the PingOne cloud directory, Salesforce, or Google Apps. Still others might be individual customers, accessing apps by authenticating via Twitter or Facebook. A true Cloud IAM platform must support a myriad of identity sources, and route those sources only to correctly authorized resources. Some simple best practices are listed below to help ensure that assertions from one context are not maliciously manipulated to end up in other contexts. 5

6 SOCIAL NETWORK VERIFIED CHECKING When accepting assertions from social networks, it s critical to understand whether those addresses have been verified. Some social networks include a separate attribute to indicate a verified address. Networks such as Google, that use the OpenID Connect identity standard, offer a boolean attribute that is set to true if the is verified. Others offer different assertions about account verification (for example, Facebook will set a verified attribute for an account only if the user has registered for mobile, confirmed their account via SMS or entered a valid credit card). If your resource is not particularly sensitive, you may choose to accept any assertion. But if your resources are more privileged, rejection of nonverified addresses is an important best practice. FEDERATED PARTNER DOMAIN LIMITS In situations such as supply chain environments or multi-tenant SaaS apps, where your enterprise IDaaS platform is accepting assertions from multiple identity providers, it s important to be sure that one IdP can never make assertions that imitate a user from another. An example of this kind of abuse might be the IdP at partnerb.com attempting to send an assertion to your enterprise IDaaS platform for johnsmith@partnera.com. It s critical for identification of any user in a multi-idp environment to be calculated as a function of both the assertion subject and the IdP. An assertion for johnsmith@partnera.com that comes from Partner B should result in one of two outcomes: A new user is created within the Partner B authorization context that s unrelated to the possibly existing user within a Partner A authorization context. This is common in true multi-tenant environments. The assertion should be rejected. The simplest best practice for enforcing this policy is to set an expected domain for each IdP, and reject all assertions whose subjects are not within that domain. In our example then, all assertions that come from Partner B are compared against the partnerb.com domain, and assertions that arrive from Partner B with a partnera.com domain are automatically rejected. CLOUD IAM - IDENTITY SOURCE ASSERTION CHANNELING EMPLOYEE RESOURCE DOMAIN PUBLIC IDAAS TARGET RESOURCE DOMAINS IDENTITY BRIDGE POLICIES: SUBJECT DOMAIN MATCHES CHANNEL PARTNER A RESOURCE DOMAIN PARTNER B RESOURCE DOMAIN 6

7 CHANNEL TRACKING POLICIES Every federation point in an enterprise IDaaS platform should track not just the subject of a given assertion, but also the channel by which that assertion arrived. When transforming assertions in a federation hub, the hub should populate either the SAML 2.0 Authenticating Authority envelope element, or allow for a SAML attribute to be configured, containing some identification of the originally authenticating IdP. Logging of that element, in conjunction with the federation hub entity ID and the SAML subject, allows for strong forensic and monitoring data and highlights any anomalies. The best practices discussed in this section are all intended to ensure that customers or partners can t manipulate the data in assertions to exceed their originally intended context. Regular review is a necessary part of ensuring that your platform does what you think it does. CHANNELS FOR API-BASED TECHNOLOGIES When using protocols such as OAuth or OpenID Connect for multi-tenant applications, administrators must still always consider the identity in the context of the issuer of the assertion. In the case of OpenID Connect, validation of the issuer is built into the protocol. Using OAuth 2.0 alone for identity purposes is explicitly not a best practice, and should be avoided. For more information, please see to understand the risks. Scopes are additional tools for the administrator when using OAuth 2.0 and OpenID Connect. Some organization choose a oneto-one matching between scopes and clients, so even if Partner B attempted to assert a subject in the Partner A domain, the scopes requested were by definition only applicable to Partner B. Therefore, the client would be denied access to Partner A data regardless of the identity. BEST PRACTICE #3: ADD FACTORS TO PASSWORD SIGN-ON If a stolen password is all an attacker needs to legitimately access your organization s data, you have a big problem. End users tend to register their corporate addresses at all sorts of websites. Sometimes, end users reuse passwords at those sites that they have also used for corporate resources. If any domain is breached where a user has chosen to reuse a corporate /password combination, attackers can simply try those credentials everywhere to see if something works. Even if it doesn t work today, it might the next time, because as users are forced to rotate passwords, old passwords tend to come back into play. Adding at least one additional factor to the authentication ceremony is a critical mitigation to the credential reuse and farming problem. This puts a stop to the opportunistic hacks where attackers blindly try username/password combinations just to see what they can get, and it forces attackers to work harder to get that first foothold in your environment. There are many inexpensive options for second-factor authentication on the market today that also have good usability for users. Specifically smartphone-based solutions offer interesting options for organizations, as they leverage a device that users always have with them. 7

8 From an enterprise IDaaS perspective, authentication services are easy to layer and can be inserted in almost any order. Because the architecture is federated, implementers can change and mature their additional factors without any impact on downstream applications. This gives a lot of flexibility to play with options and find which solution strikes the right balance of usability and security. CLOUD IAM - ADMINISTRATOR ACCOUNT PROTECTION PRIVATE RESOURCE DOMAIN PUBLIC IDAAS TARGET RESOURCE DOMAINS IDENTITY BRIDGE PARTNER B RESOURCE DOMAIN Complex organizations may also use contextual elements to passively detect anomalous situations for example, understanding whether an authentication request has come from a region where the user is known not to be. CONCLUSION A cloud IAM architecture is a combination of services and software that collaborate to mitigate each other s risks. Best practices for cloud IAM platforms include the strong requirement to eliminate the risk of standalone administrator accounts, protect against manipulation of assertion routing by users and partner domains, and add factors to password authentication to protect against opportunistic use of hacked or farmed password credentials. Because cloud IAM is infrastructure, not just SaaS, extra attention to these kinds of best practices is critical. Auditing and monitoring is a common theme across all best practices, as a watched infrastructure gives fewer options to attackers. Attempts to probe defenses are much more likely to be identified when centrally scrutinized. When patterns can be seen across resources, administrators have a much better understanding of the big picture. Ping Identity stands behind all of these best practices. Contact a representative for more information about how our software can be used to implement all of these best practices and more. Ping Identity stands behind all of these best practices. Contact a representative for more information about how our software can be used to implement all of these best practices and more. ABOUT PING IDENTITY: Ping Identity leads a new era of digital enterprise freedom, ensuring seamless, secure access for every user to all applications across the hyper-connected, open digital enterprise. Protecting over one billion identities worldwide, more than half of the Fortune 100, including Boeing, Cisco, Disney, GE, Kraft Foods, TIAA-CREF and Walgreens trust Ping Identity to solve modern enterprise security challenges created by their use of cloud, mobile, APIs and IoT. Visit pingidentity.com. 8 # v00b