We've had quite a few geeks get in touch with questions about the Quaker Cloud. Here are some of the most common. 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.
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?
The server is located in 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.
What kind of redundancy that is built into this system?
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.
Would there be some sort of a service level agreement?
The full contract and agreement for using the Quaker Cloud is available here.
Are all the administrators Quakers or would there be partners involved?
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.
If so who are the partners and what would they be doing?
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 will be interacting with.
Would there be a helpdesk and if so would they all be Quakers?
The helpdesk is run in-house at FGC, so all helpdesk staff are FGC staff.
The primary helpdesk staff person, Erin, is not Quaker, but she is familiar with Quakerism, Quaker structures and comfortable working with Quakers, 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 kind of understanding that would exist around data security such as data encryption at rest and data encryption while in transit?
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 a few times the life of the universe to decrypt a reasonably strong password in use at 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, date 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
What kinds of password/passphrases policy exists for administrators at FGC performing admins tasks?
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 first or last location in the password.
At the moment, the administrative passwords are long pseudo-random strings.
Can a meeting really store sensitive data on the cloud?
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’ve actually 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 penetration test and security audit of the system and the code. After that, I will perform periodic regular testing myself using similar techniques.
If FGC is subpoenaed, how would it be handled?
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.
So, I don’t have a firm answer on this topic, but I hope to be able to offer one soon.
What kinds of Disaster Recovery planning and Continuity plan would exist?
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.
Again, the service is only in beta at the moment, and I expect more extensive disaster planning and a reduced time to recovery as we approach launch.
If a meeting decides to participate, are there tools to help migrate data in?
Yes, though they are not available as part of the beta. We expect to be able to offer some import options around launch.
If there is an urgent need to import data as part of the beta, a meeting can get in touch with FGC staff and we can provide the import in-house.
If a meeting decides to withdraw, are there tools to help migrate data out?
Yes, we are still working on the form of the export. My sense at this point is 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, it may come out as a SQL or csv file, I’m not sure.