Nowadays people are cautious about cloud computing because of data security and privacy issues. Time cockpit is a SaaS offering in the cloud. In this article I want to describe in detail how we designed, developed, and how we operate time cockpit in order to be secure. Depending on their use cases, our customers can use time cockpit in two different ways:
- Online in the browser by logging in to https://login.timecockpit.com. This option is typically used if a customer works on a foreign computer (e.g. computer at a customer site) and needs access to her data in time cockpit.
- Offline-enabled full client which regularly synchronizes with the time cockpit database in the cloud. Customers who travel a lot typically prefer this option as it allows them to work with time cockpit even if they have no internet or work with a slow connection.
Therefore, time cockpit consists of server- and client components which have to be protected. In the following chapter I describe the security concept for time cockpit's server infrastructure. Later you can read more about client-side security.
Time cockpit is a multi-tenant system and therefore separation of tenants is an important topic. In this article I describe how we do tenant separation on database- and application-level. The last chapter of this article is dedicated to a data category which is specially protected in time cockpit: The Activity Log collected by time cockpit's Signal Tracker.
1. Time Cockpit Server Infrastructure
The entire server infrastructure of time cockpit consisting of application- and web-servers, database servers, and storage servers runs in the Microsoft Windows Azure cloud computing platform.
1.1 Data Center Location and Data Privacy
At the time of writing, all server components of time cockpit are installed in European data centers inside the European Union.
A detailed description of data privacy policies can be found in the Privacy subsection of the Windows Azure Trust Center. We are a Windows Azure Volume Customer and therefore the content regarding the E.U. Data Protection Directive applies to our time cockpit systems in Windows Azure.
1.2 Platform as a Service (PaaS)
We only use Platform as a Service (PaaS) offerings and do not maintain and use Infrastructure as a Service (IaaS). Therefore we do not maintain the Windows operating system (e.g. installing servers, installing service packs and hotfixes, etc.) or other server-based Services (e.g. SQL Server) on our servers ourselves.
Using PaaS instead of IaaS is a core element of our security strategy. Having Microsoft maintaining all our platform components in a fully automated process, we can focus on the time cockpit application. If you want to know more about security-related topics concerning PaaS offerings in the Windows Azure platform, the following resources could be interesting for you:
The following list provides an overview of all PaaS components that we use for running the time cockpit SaaS service:
1.3 Certifications
The Windows Azure platform complies with multiple data protection and security standards including ISO/IEC 27001:2005 as well as SOC 1 and SOC 2. A detailed list of certification can be found in the Compliance subsection of the Windows Azure Trust Center.
Note that at the time of writing the Windows Azure SQL Database service has not received ISO 27001 certification yet. However, if ISO 27001 compliance of the database is important for a time cockpit customer, we can support the customer to run time cockpit based on a compliant version of SQL Server in Windows Azure using Windows Azure Infrastructure Services. If you are interested in this option, please contact support@timecockpit.com.
1.4 Transport Layer Security
All traffic from and to time cockpit servers is protected by TLS/SSL.
- All public time cockpit websites can be accessed using http or https.
- The self-service portal for which you have to log in can only be accessed using https. The related SSL certificates are managed by us.
- The REST web services used by the time cockpit browser client also use https. The related SSL certificates are managed by us.
- The REST web services used to access storage clusters use https. The related SSL certificates are provided and managed by Microsoft.
- The time cockpit database servers require SSL-encrypted TDS connections (Tabular Data Stream) independent whether the connection comes from a web server or from a client PC. The related SSL certificates are provided and managed by Microsoft.
- Traffic between Windows Azure data centers is encrypted by Microsoft. Details about these security features can be found in Windows Azure Support pages.
1.5 Credit Card Data
We never store credit card data in any of our databases. Credit card handling is done using services of our partner Stripe.
1.6 High Availability Clusters and SLA
Server systems of time cockpit are implemented as failover- or load-balancing-clusters.
- All web servers that provide the REST web services for time cockpit are load-balancing clusters consisting of at least two deployed instances. Therefore Microsoft gives us an SLA of 99.95%*.
- All SQL databases of time cockpit are failover clusters consisting of three nodes. A detailed description of clustering in Windows Azure SQL Databases can be found in MSDN. The SLA for SQL databases provided by Microsoft is 99.9%*.
- All storage servers are auto-scaling clusters where data is stored on at least three different servers. Geo-replication is turned on so data on storage servers is automatically replicated to a second data center in the same geographical region. There it is stored on at least three different servers, too. Microsoft provides an SLA for storage services of 99.9%*.
*) For details about SLAs see Service Level Agreements subsection in Windows Azure Support pages.
1.7 Firewalls
Windows Azure provides comprehensive firewall infrastructure for all of time cockpit's server components.
- A description of the general security design in Windows Azure can be found in Windows Azure Support pages.
- SQL databases are especially protected in Windows Azure. A description of the SQL firewall which we use in time cockpit, too, can be found in MSDN.
1.8 Backup and Disaster Recovery
The Windows Azure Platform provides backups for disaster recovery out of the box (see e.g. this article in MSDN for a description of database backups for cases of simultaneous or catastrophic hardware and system failures). Additionally, we backup time cockpit databases into Windows Azure Storage daily. These backups are transferred to a second data center in the same geographic region automatically.
Note that we currently do not offer a guaranteed service level for the backups we create and we do not generally make them available to customers. We can support customers for setting up custom backup strategies to protect themselves for unwanted modifications/deletions or widespread loss of data center facilities. If you are interested in this topic, please contact support@timecockpit.com.
2. Multi-Tenancy
2.1 Introduction
Time cockpit is a multi-tenant system. That means that a single server farm serves multiple customers. Time cockpit was built with multi-tenancy in mind from the first day on. In this chapter I describe the mechanisms we implemented to ensure proper separation of tenants.
2.2 Tenant Separation on Database Level
Time cockpit does not use a shared-table approach. Therefore we never store time tracking data of multiple tenants in a single table. Instead, we separate tenants using separate databases, separate database clusters, or separate database schemas.
- When a customer registers for time cockpit, we create a dedicated SQL Server Schema in one of our production database clusters.
- For every user that is created for a specific tenant, we create a dedicated SQL Server User with a strong password automatically. The user's access permissions are strictly limited to his tenant's schema.
For customers who want even stronger separation, we support storing their tenant's data in a separate database cluster. This cluster can either run in our Windows Azure subscription or - if the users wants full control over all aspects of his time cockpit database - in the subscription of the customers.
At the time of writing we do not have a formal pricing model for providing a separate database cluster for a single tenant. Our current practice is to offer this service for free for time cockpit customers with at least 20 active users. We charge a small setup fee for smaller tenants who still want to have a separate database cluster. If you are interested in this offering, please contact support@timecockpit.com.
2.3 Tenant Separation on Application Level
Time cockpit uses a domain-specific query language (TCQL) for accessing a tenant's database. TCQL was designed with multi-tenancy in mind. It injects the previously mentioned database schema into database query at a very low level. Therefore no developer can forget about filtering on a tenant's schema. Even if there would be mistake in this logic, the access permissions on the database level described above would prevent showing data to a wrong tenant.
2.4 Running Custom Script on the Server
One of the unique features of time cockpit is extensibility. Our customers can change the data model of their database and they can automate processes using scripts. These scripts typically run in the time cockpit full client. In this case multi-tenancy is not relevant because one full client is only connected to one tenant.
By default, custom scripts cannot be used in the browser client because they would be executed in the multi-tenant server farm. If a customer wants to enable certain scripts in the browser client, these scripts must have been manually inspected by our developers. They check if database access is only done using the official database access layer of time cockpit. Scripts are generally rejected if they perform security-critical operations (e.g. try to access the file system). If a script has successfully been checked, it is digitally signed.
The time cockpit server infrastructure only executes time cockpit scripts which are digitally signed.
2.5 User and Password Data
Data about time cockpit users and password are not stored in the tenants' databases. We store them in a separate place.
Time cockpit passwords are not stored in plain text. We store a saltedSHA1 hash for passwords.
3. Client
In order to enable offline work, the full client of time cockpit stores data on the PC where it is installed. Data and/or configuration changes are synchronized automatically. By default this is done every 15 minutes; this interval can be changed if necessary.
The time cockpit full client contains functions which help to protect its locally stored data:
- Sensitive data (e.g. time cockpit user name, time cockpit password, personal signal data password) is encrypted using RSA/Rijndael. The RSA key is stored and protected by a Windows Key Container in the user's Windows Profile (for more, technical information see MSDN).
- The local time cockpit database is password protected (for more, technical details see MSDN) and encrypted (for more, technical details see MSDN). Note that this mechanisms provides only basic protection. If you want to protect your time cockpit data in case of e.g. a stolen laptop, you have to use common disk encryption technologies (e.g. Windows BitLocker, TrueCrypt).
- Data which is automatically collected by time cockpit's Signal Tracker is AES-encrypted (256 bit key length) with a strong, auto-generated key. This key is protected by the user's personal signal data password. This password is never transferred
It is important to note that time cockpit by nature cannot fully protect local data from users who have full access to your PC. The security of the time cockpit full client is primarily determined by the security of the PC. Customers have to care for appropriate security mechanisms on the PC themselves. Microsoft provides more information about how to protect your Windows PCs (e.g. encrypt disks with BitLocker, use appropriate password policies, use anti-virus and malware detection software, keep your PC up to date, etc.).
4. Encryption of Activity Log Data
Data in time cockpit can be divided into two categories:
- Master and time tracking data (e.g. customers, projects, tasks, time sheet entries, invoices, etc.)
- Data collected by time cockpit's Signal Tracker
Master and time tracking data is stored in relational databases. On the server, this data is not encrypted. On the client, the local time cockpit database is password-protected and encrypted. For details see...
Automatically collected signal data (e.g. computer activity, active window title) is especially protected. Data privacy is an important concern in this area. To protect signal data, time cockpit encrypts it whenever it is stored on the client and on the server:
- Data which is automatically collected by time cockpit's Signal Tracker is AES-encrypted (256 bit key length) with a strong, auto-generated key.
- The key mentioned above is derived (RFC 2898) from the user's personal signal data password. This password is not recoverable and is never transferred into the cloud. If a user wants to access her signal data on multiple devices, she has to manually type in the signal data password on all devices.
By encrypting the user's activity log with her personal password, time cockpit makes sure that other users who do not know this password can decrypt and read the activity log. Time cockpit does not contain any functions which enable sharing ones activity log or analysis of the activity logs of multiple people by e.g. a team leader.
5. Additional Resources
comments powered by 