Protecting Azure Infrastructure
In this series we discuss how the Centrify platform can secure infrastructure running in Microsoft Azure. For those who are not familiar with Centrify, here’s an overview of the Centrify Platform and capabilities:
In this first part, we’ll focus on securing access to the Azure Portal using Identity Service.
There are two strategies that can be used:
- Protecting shared credentials (like the original o365 or Azure subscription account)
- Federated SSO and just-in-time provisioning (no need to deploy an ADFS infrastructure)
Both strategies can be enhanced with:
- Workflow and Approvals
- Policy and Multi-factor authentication (including risk-based)
Protecting Azure Portal Shared Credentials
Shared Credentials in Azure may be sourced from different directories, but the most common use case is the subscription account. This is typically the e-mail address of the user started the account. This account has all the access (typically a Subscription Manager). If your organization is already using Office365, then this is the “@yourdomain.onmicrosoft.com” account.
In this cases, you can use the Password Wallet capabilities of Identity Service to provide fast deployment, least access management, policy controls, strong authentication, accountability and documented approvals. Here the features that enable all these benefits:
- Turnkey App template
- Role-based Access Control (leveraging Identity Service roles and Active Directory groups)
- Account Mapping flexibility
- Policy Engine and Multi-factor Authentication
Centrify also provides Risk-based Access Control.
- Workflow and Approvals (Natively or via ServiceNow™)
Centrify can do native or ServiceNow™ approvals. For more informationa about ServiceNow integrations, visit the ServiceNow TechCenter.
Providing Federated Access and Just-in-time Provisioning for Azure
Just like any other SaaS application, Azure provides federated access. In this particular case, the same functionality used for Office365 federation, provisioning and license management. The benefits of leveraging Identity Service is that there's no need for the additional complexities and overhead of native solutions like ADFS, plus, there's added capability like we've seen above.
Benefits of using Federation and Provisioning in Azure
Users come from AD as the identity source. This means that any add/moves or changes will reflect in the user's ability to access the service or any entitlements.
AD Security groups provide 2 great benefits around entitlements and provisioning:
- This is because direct assignment paths are not the recommended practice.
- You can allow the provisioning of access and roles from a single AD group membership.
Traditionally, Microsoft has positioned DirSync as the tool for O365 provisioning; along with ADFS these are mature and effective solutions, however, they promote fragmentation. With Centrify, both federation, policy, workflow and provisioning settings can be managed with a single administrative experience.
This is another component of O365 and Azure. Centrify allows the centralization of these efforts and the allocation based on different provisioning rules.
For more information about how to leverage Identity Service for Azure or O365 federation, provisioning or license management, visit the O365 TechCenter.
Centrify provides several dimensions to measure application access or to determine assigned or provisioned apps.
This allows security operations to obtain timely information about events, plus the ability to attest application assignment or provisioning.
Centrify Identity Service will allow you to meet or exceed the controls required to secure Azure portal access and to provide granular access werther you are leveraging the Azure's cloud directory or are federating with your existing on-premises Active Directory.
Resources and Related Links
- Office365 TechCenter: http://community.centrify.com/t5/TechCenter/Office-365-TechCenter/ba-p/25846
- ServiceNow TechCenter: http://community.centrify.com/t5/TechCenter/ServiceNow-TechCenter/ba-p/26601
- Amazon AWS TechCenter: http://community.centrify.com/t5/TechCenter/AWS-TechCenter/ba-p/25847
- Risk-based Access Control: https://www.centrify.com/solutions/why-risk-based-access/
The Centrify Community has some great resources when it comes to IBM DB2 integration with Active Directory using Centrify. But, have you ever wanted to quickly set up DB2 in a test environment to play with these integrations? By following this article, you can!Read more...
This article will describe how Centrify helps customers address disjointed AD and DNS namespaces to achieve Kerberos SSO.
Organizations can always count with the reliability of IBM hardware, operating systems and utilities for mission critical applications. That’s why Centrify has invested in certifying the product lines with IBM infrastructure.
This post discusses the DB2 SSO Module; this plugin (like the Apache HTTP and Java plugins) leverages the Active Directory integration capabilities and robustness of the Centrify agent to provide additional value and functionality to DB2 implementations.
The DB2 plugin provides the following benefits:
- No need to keep users local to the UNIX/Linux system to support DB2: When used natively, DB2 users need to have user accounts in the local /etc/passwd file. The DB2 enables AD users to access DB2 so the benefits of Unified Identity, Centralized Administration, Streamlined Authentication and Policy Enforcement are organically attained.
In practical terms: no more getting dinged by auditors when the account of a long-gone user is found active in the /etc/passwd of a DB2 system.
- Long login names: Support for logins that are longer than 8 characters
- Single Sign-on (SSO): Centrify enables SSO to DB2 leveraging the GSSAPI
- Active Directory Group Support: AD group memberships can be leveraged to grant entitlements inside DB2.
This is one of the best Database to AD integration models out there.
This article covers setup, configuration and testing of the DB2 moduleon Linux 64 bit in a lab environment. We will focus on the User/Password and Group Plugin first since they enable a UNIX/Linux admin to set it up without any AD requirements. In a follow-up post we'll cover the SSO GSSAPI plugin.
Like any other DBMS, a true production implementation requires planning and understanding of the current environment.Read more...