Office365 is a cloud based solution that provides hosted email, collaboration, and IM solution, enabling organizations to quickly implement these capabilities without needing to implement large, in-house infrastructures to support the products. However, as organizations look to move to cloud based solutions, and Office365 in particular, due diligence and planning should be given to preparing the internal security infrastructure, and the user experience aspect. There are 3 steps that you can start tackling to prepare for your deployment (we assume, of course, that the Office365 service itself is secured).
The steps are:
• Step 1: Identity and enabling client access to Office365
• Step 2: Federation between cloud and on-premises AD FS
• Step 3: Office365 protection using on-premises AD RMS
Step 1: Identity and enabling client access to Office365
The first step in preparing your infrastructure for Office365 is based on identity management and web gateway traffic load. Office365, as well as most cloud based solutions, require you to provision users into the cloud service, and manage those user identities and attributes, such as role information, contact information, and so on. Office365 includes a DirSync Tool to facilitate the initial provisioning and synchronization of users into the service; however, the axiom of garbage in, garbage out still applies here, and the data in Office365 will only be as good as the data in your production Active Directory forest. To ensure a proper, normalized, and clean Active Directory, an organization must have a well-defined identity management process, and an enterprise class tool to facilitate the synchronization of attribute information, as well as a consistent provisioning/de-provisioning process. Forefront Identity Manager (FIM) 2010 is Microsoft’s solution for identity management, provisioning, and synchronization, as well as user self-management tools. After identity management, attention and planning will need to be given to the internal and perimeter gateways, especially if web traffic filtering or https inspection is being used. Because all access to Office365 is done over the public Internet (goes without saying), organizations can expect significant load on their filtering devices, and need to account for the extra connections and traffic by either scaling out their current solutions by adding new hardware, or upgrading existing hardware. This is best done by having a reliable monitoring infrastructure in place to gather real metrics, and base the decisions on infrastructure changes with the metrics.
Step 2: Federation between cloud and on-premises AD FS
As part of the initial planning phases, organizations need to review and understand how users will be authenticating to Office365, be it a dedicated, separate user name and password, or with a single-sign on solution using federation services. Federation is a set of standards that define how organizations can securely access other organizations resources, without the need for managing disparate identities for each system. Federation, and AD Federation Services in particular, enables users to authenticate against their production Active Directory, obtain a token or claim, and pass the claim onto Office365 for access. This is seamless to the end user, and provides for a much more secure deployment, and less user pain, as they will never need to know their password for the Office365 infrastructure. In order to implement federation, a federation server is required that will create the correct claim for the federated service (Office365). This is an on-premises solution, and based on your requirements, may also need to investigate using an ADFS Proxy server, which can service federation token requests from external users. Federation with Office365, as with most other cloud solutions is an all or nothing proposition – you have to either federate all users, or none at all. That being said, it is recommended to validate federation with a dedicated test instance of Office365 during your migration planning, and obtain end-user feedback on the overall experience.
Step 3: Office365 protection using on-premises AD RMS
At this point, we have Office 365 user access enabled, we are good on our network devices, and we have single sign on! Life is good, the CIO is happy, and IT is celebrating the decommission of the legacy Exchange infrastructure. However, a lone voice among the jubilant crowd asks – “What about securing content inside of Office365?” Sure, we know that the application is secure, and that the datacenters hosting the servers are harder to get into than Fort Knox, but what about the information, documents, intellectual property that is being stored in the cloud, in Exchange, and in SharePoint? This is where Active Directory Rights Management Services comes in. Active Directory Rights Management Services (or ADRMS) is an information rights management product that encrypts and sets permissible activities for content stored in a file share, on SharePoint, or in Exchange. Office365 is ADRMS aware, but it will require organizations to host their own infrastructure to allow users to obtain the correct certificates so they can open and access content. Once this infrastructure has been implemented on-premises, organizations will need to synchronize encryption keys with Office365, as well as publish the RMS infrastructure to the outside world, so users can open their content seamlessly.
Summary
Office365 is an excellent service offering for mid-size organizations; however, care and attention needs to be paid to your own security infrastructure, processes, and technologies as part of the overall deployment, and not just treat an Office365 deployment as a data migration exercise. Once you have taken care of all aspects of the security infrastructure, organizations will find the migration experience to be more satisfying, and meet more of the business goals, than a straight migration would have.
