# Security of Data
Security is always a challenge, especially when trying to deal with it in the cloud. Due to the public nature of the cloud, there are many possible attack vectors, including the well known Denial of Service (DoS) type of attack. At FlyData, we take a proactive approach to security. Keeping up with the various attacks, whether it be Man-in-the-Middle (MITM) or some type of authentication attack, can be a losing battle. From our experience, there will always be some type of yet unknown attack. Since we ingest data from various RDBMS and other sources, we need to make assurances that any data passing through our cloud will be safe. Although we don’t store any data for the long-term, we do some amount of buffering on the servers during the data transfer in order to handle possible connection issues gracefully. Our policy is to send the data to the destination (ie. S3, Amazon Redshift, etc) as fast as possible, with the minimum amount of buffering taking place.
# Secure Sockets Layer (SSL)
Let’s follow along the typical data flow, and see what security measures we put into place. Starting with the data extraction process, we currently offer two options for how to extract data from your data source (you can read more about this process, here). The default option has FlyData directly monitoring your data source. We use OpenSSL along with the source libraries (ie. libmysqlclient) to encrypt the transfer. As an example, MySQL has support for SSL using either OpenSSL or yaSSL implementations and along with 2048-bit RSA keys; we will use the built-in support that is provided on the source database. When using a provider hosted RDBMS solution like Amazon RDS, they also provide this feature and we will make use of the same libraries to access these sources. The alternative option involves using an installable FlyData Agent, and having it read your data source. With the use of OpenSSL and 2048-bit RSA keys using 256-bit AES encryption, we can encrypt the tunnel from the FlyData Agent, installed within your cloud, to our cloud. Since the Agent is the one reading from your data source within your environment, the transfer from the Agent to the cloud is encrypted.
# Virtual Private Cloud (VPC)
As of this writing, the FlyData Cloud is in an Amazon VPC, provided by Amazon Web Services (AWS). This provides an isolated cloud apart from the older Amazon EC2 Classic, and creates some segregation within AWS’s public cloud. By putting our service infrastructure within a VPC, the heavy processing related to the transformation of data and parallelization of processes is isolated from the public network. For FlyData Operations, we make use of a Virtual Private Network (VPN) to gain direct access to any resources within the VPC.
# AWS APIs
We make use of AWS APIs for accessing various resources such as Amazon’s S3 or Redshift. By using Amazon’s APIs, we can make use of Amazon’s secure authentication methods for access to various resources.
We have a continuous process of monitoring all security channels. Our team are constantly engaged in discussions about possible security risks within applications and/or libraries that we might use in our infrastructure. FlyData makes use of open-sourced software and we analyze all security vulnerabilities affecting any application or library used by FlyData. Once a vulnerability is discovered, we will assess and make efforts to patch the affected application or library as soon as possible taking into account the severity level.
With the above processes, we do our utmost to maintain security and customer confidentiality, as it is the top priority for a service like ours. We have recently undergone processes for being EU Safe Harbor certified, and will continue to look to obtaining other certifications as well. We also continue to make improvements on our current process. As mentioned, it is a never-ending battle against attacks, and continuing to improve is the key to keep everything protected.