How to Move Your Messaging Infrastructure to the Cloud

 
 
By Gregory Shapiro  |  Posted 2010-09-28
 
 
 

How to Move Your Messaging Infrastructure to the Cloud


Today, more and more companies are moving to the cloud. It is estimated that almost half of enterprises are considering moving their IT infrastructures to the cloud. In the midst of enterprises looking to move to the cloud, their main concern is the security issues and risks involved. The majority of enterprises note these as their top concern and for good reason. The reality is that these moves represent both a challenge and an opportunity.

At first, it may seem as if moving your e-mail infrastructure to the cloud is a no-brainer, as the upkeep, capacity planning and troubleshooting becomes someone else's problem. However, the benefits outsourcing to the cloud offers brings risks that need to be carefully weighed for each portion of the e-mail infrastructure-before making a decision to keep it in-house or put it in the cloud. In the end, the most likely outcome is a hybrid infrastructure that makes use of both cloud services and in-house infrastructure.

E-mail infrastructure's three layers

Before we look at the benefits and risks of moving an e-mail infrastructure to the cloud, we need to define the three layers that make up a modern e-mail infrastructure. The first layer, the Gateway Layer (aka, the External Protection Layer), is found in the DMZ. This is where you typically find inbound malware (spam, viruses, etc) filtering, connection controls, reputation services, inbound verification [recipient validation, sender authentication via DomainKeys Identified Mail (DKIM), etc], simple routing, and security.

The second layer is the E-mail Backbone (aka, the Internal Layer) and it is typically found in the internal network. This layer performs bidirectional policy, directory-driven security, enforcement, and intelligent routing. It performs these duties by leveraging information in the enterprise directory and performing deep message inspection for outbound content policy to protect against leaking sensitive information. This layer is also likely the injection point for other applications in the enterprise that send outbound mail (for example, customer care, notifications, etc).

The third layer is the Mail Store Layer (aka, the Groupware Layer). Also found on the internal network, this layer encompasses the mail stores with simple policy and user-to-user message delivery. In large enterprises, there are often many solutions and servers in use, often geographically dispersed and sometimes segregated by business unit. It is the E-mail Backbone's job to properly route messages to the proper server in this situation.

Weighing the Benefits and Risks


Weighing the benefits and risks

Now, let's look at the five benefits and associated risks of moving these pieces of infrastructure to the cloud. These items involve costs, responsibility, trust, control, functionality and security.

1. Costs

There is no doubt that outsourcing to the cloud lowers infrastructure costs. There is no need to purchase and maintain servers, plan for hardware refresh cycles, purchase server software licenses, etc. This also frees up IT resources to focus on other strategic, possibly revenue-generating, projects.

However, unlike an in-house infrastructure in which buying equipment and staffing are usually fixed costs, paying for a hosted service is a variable monthly cost that may change outside of your control-especially if pricing is based on volume. Some services may reduce bandwidth needs and costs (for example, outsourcing the External Protection Layer's incoming message cleansing), but others may increase bandwidth needs.

Finally, outsourcing infrastructure into the cloud will certainly reduce administrative and operational personnel needs as described earlier, but it may increase internal help desk or support demand. This can be mitigated by transferring services to the cloud that don't impact users directly.

Responsibility and Trust


2. Responsibility and trust

While outsourcing the responsibility for one or more e-mail infrastructure layers can be appealing, the risks associated with the trust you put into that provider (and beyond) needs to be closely examined. Each layer exposes more sensitive data and needs to be reexamined before moving that layer to the cloud.

In the External Protection Layer, this may only be a list of valid e-mail addresses for recipient validation. However, in the Backbone Layer, this may be a substantial amount of directory data in order to implement policy and routing based on directory information (department, manager, location, etc). Your use of cloud services means you not only need to trust your providers but also need to trust your provider's partners.

3. Control

Unfortunately, when it comes to control, there isn't much to offer in terms of benefits. Instead, I include it as food for thought when deciding which portions of the e-mail infrastructure to send to the cloud. Using another provider can take away your control of services in data in various ways. Examples include:

-Lack of control over data retention policy for backups, storage, logs, etc.

-Providers may be subpoenaed and required to turn over your data without notification due to gag orders (for example, National Security Letters).

-Little to no control over provider's maintenance cycles or downtime.

-Providers or their partners may be acquired by organizations that may have different privacy policies, partners, terms of service, etc. They may also go out of business.

The importance each of these depends on the corporate culture and the portions of the infrastructure being considered.

Functionality


4. Functionality

Cloud providers have a high level of expertise in handling infrastructure needs and serving applications. Their solutions will offer all of the common functionality needed. They are also able to handle operational issues such as backups, log management, etc. Pay close attention to the following items:

-Make sure there is a straightforward migration methodology and appropriate tools to complete a smooth transition.

-Internal, mail-generating applications need to be modified to use external cloud services.

-Complex routing or policy, especially regulatory, may not be achievable in the cloud.

-Archiving and control of what is put in the archive may not be available and also presents regulatory, control and confidentiality issues.

-May have limited access to auditing information for compliance and mail logs to track problems.

5. Security

I've saved the most important for last because security considerations must include the previous three topics: trust, control and functionality. Each infrastructure layer has different levels of security exposure. Transferring the burden of securing the External Protection Layer (normally found in the DMZ) to the cloud gives enterprises the opportunity to eliminate most of the inbound threats e-mail services carry.

However, when considering moving the Backbone or Groupware Layers to the cloud, security presents the biggest and most important risk. Doing so exposes all of the data at rest necessary to implement enterprise policy and deep content inspection, including enterprise directory data, sensitive documents to be fingerprinted, and archived and quarantined data, to name a few. The Groupware Layer adds all of the employee mail to the data at rest and the data in motion, including internal mail among employees that was never meant to leave the enterprise network.

Migrating Your Messaging Infrastructure to the Cloud


Migrating your messaging infrastructure to the cloud

As you can see, these five items are highly interrelated and interdependent. Enterprises can use the following checklist-which includes business requirements and examples I've recently observed-when considering the move to cloud computing.

1. Outsourcing the External Gateway Filtering Layer

Compare the bandwidth and infrastructure costs to the service and support costs. What security sacrifices need to be made to put mail cleansing in the cloud? What complex policies exist internally today that cannot be done in the cloud?

2. Outsourcing the Groupware Layer

What is your comfort level with enterprise data being stored externally? Can your data retention and archiving needs be met and guaranteed? How does existing data get migrated?

3. Outsourcing the E-mail Backbone Layer

Is this achievable for your enterprise? Are you comfortable with not only the data exposure but the lack of control in doing so?

In the end, who is responsible for your e-mail? Think about your own messaging infrastructure. If you use cloud services or are considering a move to the cloud, it's important to understand that. While the promises of cloud computing can be potentially realized by migrating different layers of the messaging infrastructure to the cloud, it's also critical to address the risks involved.

Gregory Shapiro is Vice President and Chief Technology Officer at Sendmail. In his tenure at Sendmail, Gregory has held prominent roles in the engineering, IT and business development departments. After four years of leading Sendmail's products in production, Gregory returned to improving those solutions, first in the business development group researching and evaluating partner products and most recently as the engineering group's chief architect.

Prior to Sendmail, Gregory began his professional career as a systems administrator for Worcester Polytechnic Institute (WPI) after graduating from WPI with a degree in Computer Science in 1992. Gregory is a FreeBSD committer, has served as program committee member for BSDCon 2002 and program chairman for BSDCon 2003. In addition, he has contributed to the past three editions of the O'Reilly Sendmail book. He can be reached at gshapiro@sendmail.com.

Rocket Fuel