Security

Hi, 

I can at least answer the first question:

since there is nothing "done" on the Exchange side with the mail there is no encryption except of TLS. The mail otherwise is not changed before sending via SMTP over TLS to the archiving service.

Christian

1. Yes, we use TLS which is a common standard for secure communication and can be considered as safe enough. No communication, neither internal nor external happens unencrypted. All stored data is encrypted as well (mainly AES).

2. No partners, ISP, contractors, etc. have access to any of our data.

3. Release what kind of information? We don't release anything to 3rd parties.

4. What exactly do you mean?

CIA is an industry acronym for Confidentiality, Integrity and Availability.  I think you answered the first two pretty well.  Availability would have to do with up time of the servers to access our data.

I'm having some healthy internal debate on whether we should go with Barracuda's on site appliance or Astaro's off site web solution.  I have enough hardware to maintain as it is so I like the idea of a simple web based solution.

I do however have to be able to assure upper management that we are not opening ourselves up to significantly increased risk by offloading what would be largely internal communications to a remote server over the internet.

I think Astaro needs to address these concerns in their product information and documentation in order to attract businesses.

FWIW, a feature request for a local mail archive store:
AMA to a local storage

Barry

Availability would have to do with up time of the servers to access our data.

AMA runs on a distributed frontend-backend-structure. We can "switch" any customer account from one frontend to another within minutes and without any customer noticing, in case any server is not available for whatever reason.

Also, it's a self-monitoring system that will send alerts to all responsible engineers whenever something appears to go wrong.

This way, there will hardly be any (unscheduled) downtime. In fatal cases (server crashes), there might be a downtime of some minutes. This should occur very rarely.
Another reason for down time might be scheduled maintenance windows (i.e. for software updates). These should never exceed a few minutes and will happen only every few months.

All mail is stored simultaneously in 3 different geographic locations.

Hello,

better late than never, also a reply from me (important topic, especially since it's so much about trust with cloud-based services.)

All stored customer data and communication is strongly encrypted *at all times*, including intra-cloud communication. Of course, some of it is temporarily unencrypted in RAM (we cannot avoid that), but anything remotely persistent -- including backups -- is encrypted. All data-processing servers do everything on encrypted data partitions. Therefore, all cloud servers cannot (re)boot on their own, but need a key that is provided on-demand by a "maintenance server" that is 100% under our (direct, physical) control and properly protected.

Integrity is provided by the fact that modified "Email objects", as they are stored on the secure long-term storage, would be impossible to decrypt and decompress. If you view an Email, it's guaranteed to be "original" (in quotes, because it's hard to tell what is original with Email in the first place ... lots of servers in between do stuff). The MS Exchange Journaling wrapper is removed by us before final storage, however.

[Edit: Previous statements about availability removed. They were not helpful.]

These, and many more details, will be provided with the documentation when we go GA. Especially for our important German market, such documentation is crucial ... so yes, there will be some and it'll be thorough.

Now to the other questions ...

2.)
No partners/ISPs/contractors require any access to customer data, so they're not getting any. Only us developers and "operators" cannot hide our own secrets from ourselves, but then we also signed an internal paper that guarantees major extra-discomfort for us in case of abuse. Nobody, who does not require access, has it ... this includes Astaro employees and management. If a customer wishes to provide access to their archive to a partner for additional services and/or support, they can do so through regular means by creating accounts.

3.)
We do not take note of the Email content or other related customer data, other than what needs to be done to be able to provide our service (e.g. by indexing text, making it available, etc.) in an automated way. Customers can, and need to, provide access to authorities on their own -- if they have to. If we are forced to take action, e.g. through an anonymous hint for illegal content in Emails of customer XYZ, our action will be to notify customer XYZ according to the law.


I hope that helped, with best regards,

Moritz

The legal aspects of offsite data have always been a question for us too.  What if some legal authority were to come to Astaro, the cloud provider, some other participant, etc. and require them to hand over a customer's data (e-mails, etc.).  What would happen?  Who would pay for, or run, a defense?  What legal system, laws and requirements would have jurisdiction across borders for actions occurring in varying jurisdictions?

From a practical standpoint, a 2nd or 3rd party's interest in fighting against disclosure will rarely be exactly the same as a 1st party.  Ultimately everyone looks out for their own best interests.

For those concerned with such issues, there are two solutions, both alluded to in the previous posts.  1.) The client maintains the data on site where they have physical control over it, or  2.) the client encrypts the data with their own keys in such a manner that there is no (practical) method of decryption by any other party.

A personal disclaimer: I Am Not A Lawyer, I cannot guarantee absolute correctness in my answer.

As I mentioned earlier, access to authorities must be provided by the customer. Just add a new user with full auditor privileges, and full access is there. The defense against this really is up to the customer. We are merely an assistant to the customer's legal obligation to archive Email. We cannot and will not take legal responsibility for the content of customer Emails: the customer has the same control over AMA as he/she would have with a physical on-site solution. As such, with AMA it's also a "1st party fight."

For European customers, data is guaranteed to be physically stored within the EU (which is important from a legal point of view.) US and other customers have their data physically located in the USA. Safe-harbor provisions do not apply; data of European customers is fully protected by European law within European borders.

Again, all of this will be properly documented for the GA ... sorry that we can't offer any drafts.

Lastly, whether the customer provides us with a private key for encryption, or we generate one ... it makes absolutely no difference. In fact, during the early stages of the AMA Beta, we still allowed customers to set their encryption passphrase. We disabled that, because nearly all of the customer-chosen passphrases were extremely weak. We now use a 64 characters long, randomly generated string. It will be made available to the customer through a secure channel in the "export archive" + "account termination" case.