Cloud - Strategic or Tactical?
Most companies do not plan their migration to the Cloud. Perhaps as a result of a question by upper management, they find-out one day that they have multiple users of cloud services in their organisation. While each application was a good idea at the time such a disparate approach means that there is no strategic vision, un-coordinated service provision, a significant training impost and little governance over Cloud-based applications and infrastructure.
Identity Management
One aspect of IT infrastructure that must be addressed when embracing Cloud services is identity and access management. It is important that an efficient mechanism be adopted to manage access to applications. It is all too common to provide single sign-on for on-premise applications and only same sign-on for Cloud applications. But this is an aggravation for users and is usually accompanied by poor password management and less than real-time identity provisioning.
Companies should analyse their identity and access management requirements and ensure Cloud applications adhere to them. In an Azure environment this means selecting the level of integration. For a basic configuration the DirSync tool will synchronise on-premise identities from AD to Azure AD (AAD) and password hashes can be stored in AAD for same sign-on. While this can be satisfactory for support of legacy applications to the Cloud it does not provide the session management that single sign-on requires. Microsoft’s solution is to install ADFS on-premises to provide federation services and automatically authenticate users with an active session to Cloud applications. Third party federation services should also be considered since they can be less resource intensive and more flexible.
For naked-Cloud users the issue becomes more of a concern because of the proliferation of applications and the lack of Azure AD. This means that identities are synchronised into multiple environments causing security and privacy concerns. Another option is to select a Cloud-based identity provider service (IDP) and require all cloud-based applications to use it. This means that Cloud applications must adhere to the SAML protocol and that the IDP must provide the required attributes. In terms of selecting the IDP this will normally be dependent upon the main provider of Cloud applications. If Okta is selected then centralising on this service might be indicated. If Salesforce is used, embracing their identity service should be considered. Another solution would be to establish your own IDP on a service such as PingFederate and require all applications to interface to it.
A note on AWS identity services: a typical recommendation is to adopt a VPN approach for hybrid scenarios. This means the Cloud environment will simply be an extension of the on-premise environment and an AD instance in the Cloud becomes part of the organisation’s AD forest. In this circumstance AWS can also offer the Microsoft Word applications in a standard format (not Office 365). This might be attractive for some organisations since it means that staff do not need to be trained on the use of Office 365. It also means that performance issues will need to be to be addressed due to the verbose nature of Windows applications. In some cases a virtual desktop integration (VDI) approach will be warranted. In some cases a dedicated “pipe” into the closest AWS data centre will be a better solution.
C U in the Cloud
Graham Willamson
