We've had quite a few geeks get in touch with questions about the Quaker Cloud. Here are some of the most common questions we've received. If you wouldn't describe yourself as a geek, you may find these answers a bit dense. Rest assured, you won't need to understand anything below to fully use the Quaker Cloud. The Frequently Asked Questions is a good starting place, if you haven't already looked there.
This started as an email exchange, so it's written in first person by FGC Communications and Web Manager, Chris Pifer.
- Where are the servers located that will host this service?
- What kind of redundancy that is built into this system?
- Is there some sort of a service level agreement?
- Are all the administrators Quakers? Are there other partners involved?
- Who are the partners and what is their role?
- Is there a helpdesk and is it staffed by Quakers?
- What steps have you taken to ensure data security? Is data encrypted in transit and when it is stored?
- What kinds of password/passphrases policy exists for administrators at FGC performing admin tasks?
- Can a meeting really store sensitive data on the Cloud?
- If FGC is subpoenaed, how would it be handled?
- What kinds of Disaster Recovery planning and continuity plan are in place?
- If a meeting decides to participate, are there tools to help migrate data in?
- If a meeting decides to withdraw, are there tools to help migrate data out?
The server is located in a colocation datacenter in the Chicago area. The site is actually running on virtual private server that is distributed across a cluster of physical servers and storage devices such that failure of any individual server in the cluster does not bring down the site. This allows us to add resources to the server with no or minimal downtime. A disk failure will degrade performance, but it will not take the site down.
Currently we are running on a single virtual server; if demand is such that we need to scale beyond that, I expect we will disperse the resources geographically such that traffic is load-balanced between servers in various locations, with hot copies of the back-end database stored in at least two physical locations.
At the time this was written, the server has been up for 3 months without a reboot. Our last reboot was for a kernel patch. Downtime was under 5 minutes.
The database and filesystem for the Quaker cloud are backed up nightly. Three copies are stored 1) in datacenter in New York 2) in the FGC offices in Philadelphia 3) on the server in Chicago. The code base is stored in a version control system that uses Amazon EC2 in Northern Virginia and on the server in Chicago, as well as on a development server in Philadelphia.
FGC staff are the only people with root access to the server. I don’t imagine this changing.
The “Administrator” for each meeting is a member/attender of that meeting. So, it’s up to the meeting to decide who that will be and to select someone they trust.
The only outside firm that we are working with on development of the Quaker Cloud is Message Agency. Their principal is an attender at Central Philadelphia Monthly meeting. As I mentioned before, we are not hosting this in a closet in our offices, so I guess you could say our hosting company VPS.net is a partner. Pieces of the Quaker Cloud will be connected with the primary FGC database system, which is built in Salesforce.
Message Agency has served as lead developer on the services building upon the widely-used and enterprise-appropriate Drupal CMS/framework.
Obviously our hosting company is providing hosting and bandwidth. We will be using Salesforce as the primary help-desk infrastructure for the Quaker Cloud, though users are unlikely to ever know they are interacting with Salesforce. Again, they are an enterprise-appropriate system that Fortune 500 companies trust with their trade secrets. They are built from the ground up using a “trust no one” model such that even Salesforce customer support does not have access to the FGC data unless it is explicitly and temporarily provided by FGC staff. In the past few years of FGC using Salesforce we’ve only had two cases when we needed to grant access to Salesforce customer support.
Finally, we are partnering with Acquia to provide enterprise-level search. The architecture and infrastructure we are using through them is built in accordance with the Federal Information Security Management Act to support a number of government clients that hold much more sensitive data that FGC interacts with.
The helpdesk is run in-house at FGC, so all helpdesk staff are FGC staff.
The primary FGC helpdesk staff person, Erin, is not Quaker, but she is familiar with Quakerism and Quaker structures, while also being able to provide meetings a bit of guidance on how they can make their websites more welcoming to non-Quakers.
I (Chris Pifer) am second tier support. I was born into the Quaker meeting in Madison, WI and I’ve been worshiping with Quakers ever since.
What steps have you taken to ensure data security? Is data encrypted in transit and when it is stored?
I’ve done a preliminary threat analysis around the data flows and data types related to the Quaker Cloud and prioritized around that threat picture.
Because people reuse their passwords on multiple services, the single most valuable piece of data FGC will be storing is the email address/password pairs created by member/attenders logging in.
As a result, passwords are the most securely stored piece of data – it would require the fastest computers in the world several times the life of the universe to decrypt a reasonably strong password in use for the Quaker Cloud.
From a technical perspective, password hashes are created using 16385 iterations of SHA-512 hash with individualized salt for each user. This means the most common tool to decrypt this data, something called a rainbow table, is useless.
We are not storing any credit card data, social security numbers, driver’s license numbers, bank information, dates of birth, or anything else that is widely recognized as sensitive data that has a market value for hackers. If at any point in the future we find ourselves storing this data, we will store it using similar encryption techniques.
Beyond this, it’s fairly uncommon for data outside these sensitive categories to be stored in encrypted form even in online banking or other secure settings.
That said, recognizing that Friends do feel sensitive about this data, all data is protected in transit via SSL/TLS
For FGC staff with administrative access, passwords must be at least 14 characters including uppercase, lowercase, numbers and symbols. If a password only has one number, it cannot appear in the first or last location in the password.
At the moment, the administrative passwords are long pseudo-random strings.
That entirely depends on how you define sensitive data. Can your meeting store social security numbers on the Quaker Cloud? No, please don't! In the course of normal operations, most meetings do not need to store sensitive information such as this, and the costs associated with building this level of security would increase the amount we would need to charge for the Quaker Cloud dramatically.
Can your meeting feel comfortable storing directory info, minutes and other related private info? Yes!
I have a personal interest in computer security. I arranged for a friend of mine who works for a large computer security firm that typically works with major banks to conduct a pro-bono analysis. We discussed the design and architecture, potential weaknesses, and system configuration strategies. We implemented the strategies suggested. In the future, I will perform periodic regular testing.
This is again a policy question which is still in the works. We don't have an answer to this yet.
For the sake of background - I spent 5 years working for AFSC in Washington, DC working on the PATRIOT Act and related privacy/security concerns. This was during a period when AFSC was under surveillance by the Department of Defense. Needless to say this is territory I've been over and these are risks I know well.
That said - there are some complicating factors which we need to consider. FGC doesn’t have legal counsel in-house or on retainer, so we need to be sure we have the appropriate infrastructure in place for this type of situation and the resources to be able to uphold such a policy. FGC’s Central Committee will decide on this policy and this document will be updated to reflect that policy.
So, I don’t have a firm answer on this topic, but I hope to be able to offer one soon.
At the moment our disaster recovery plans focus on geographically-focused single-point catastrophic failure in the datacenter.
Assuming the backup systems stay online in New York, our recovery time is under a half-day. Essentially, this is the same disaster recovery planning we’ve done for the primary FGC website.
The answer is yes and no. We do provide an automated process for setting up user accounts for your members and attenders as part of the setup of your meeting’s cloud account. As far as importing pages and content from an existing website, we’ve found there is too much variation in the structure, format and infrastructure supporting meeting websites to allow us to build an import tool. We’ve also heard from meetings that the process of migrating content between an old website and the Quaker Cloud often provides an important opportunity to review what was previously on your meeting’s website and verify it is still correct, current, and consistent with how you would like to present your meeting to seekers and newcomers.
We don’t have a clear export format/process defined we haven’t needed it yet. We do know that contact information will come out as a CSV file. Minutes will come out as an encrypted zip file. Website content is the hardest piece, and will likely come out as a CSV file.