thanks for the reply.
Please let me know how the security for data in motion and data in rest(in s3) is ensured byb attunity cloudbeam.

RegardsQ
Ram

Hi Ram,

Thank you for contacting technical support.

Data in motion is secured by using secured channel protected by AES-256 encryption. The encryption key is established via an enhanced Diffie Helman key exchange protocol (prevents man in the middle attacks using the password entered by the user on both ends). Once the channel has been established all traffic is encrypted.

Data at rest in S3 is encrypted using AWS S3 Server side encryption. Any file transmitted to S3 via CloudBeam is flagged with the “Server side encryption” so data is never stored clear-text in S3.

If there are any additional questions, please don't hesitate to contact us.

Data in motion is secured by using secured channel protected by AES-256 encryption. The encryption key is established via an enhanced Diffie Helman key exchange protocol (prevents man in the middle attacks using the password entered by the user on both ends). Once the channel has been established all traffic is encrypted.

Data at rest in S3 is encrypted using AWS S3 Server side encryption. Any file transmitted to S3 via CloudBeam is flagged with the “Server side encryption” so data is never stored clear-text in S3.

If there are any additional questions, please don't hesitate to contact us.

Thank you.

Reza K

Hi Reza,

I would like to get bit more information on the security of the communication channel in the attunity architecture. In my solution, I need to replicate data from RDS MySQL to Redshift. I have manually enforced ssl connection between MySQL and Attunity Replicate server. However I assume as per your comment rest of the lines encrypted or secured by default.

1. Between MySQL and Replicate server in EC2 (ssl enforced using odbc property manually)
2. Between Replicate server and CloudBeam AMI in EC2 (secured channel by default)
3. Between CloudBeam AMI and S3 (Secured by default)
4. Between S3 and Redshift (Secured by default)

If my assumption is wrong, please correct me if I need to do configure anything to enforce the secure channel all the way (for 2, 3, & 4 above) because that is the requirement I am working with.

I would like to get bit more information on the security of the communication channel in the attunity architecture. In my solution, I need to replicate data from RDS MySQL to Redshift. I have manually enforced ssl connection between MySQL and Attunity Replicate server. However I assume as per your comment rest of the lines encrypted or secured by default.

1. Between MySQL and Replicate server in EC2 (ssl enforced using odbc property manually)
2. Between Replicate server and CloudBeam AMI in EC2 (secured channel by default)
3. Between CloudBeam AMI and S3 (Secured by default)
4. Between S3 and Redshift (Secured by default)

If my assumption is wrong, please correct me if I need to do configure anything to enforce the secure channel all the way (for 2, 3, & 4 above) because that is the requirement I am working with.

Regards,
RP

Hello Ram,

Thank you for the follow up.

Please note that all the channels are secured by default and do not require any additional configuration on your part, as explained below:

2. Between Replicate server and CloudBeam AMI in EC2 (secured channel by default)[Reza] Correct, this is secured using the AES 256 bit SSL encryption

3. Between CloudBeam AMI and S3 (Secured by default)[Reza] Correct, The files are actually only passing through the ACB AMI in memory and are written to the S3 bucket with the Server Side Encryption enabled by default. These data files never get written to the disks of the ACB AMI.

4. Between S3 and Reshift (Secured by default)[Reza] Correct, since server side encryption is enabled on the Data Files in S3, the COPY commandused to load the Data from S3 to Redshift supports the use of AWS managed encryption keys (SSE). To protect your data in transit within the AWS cloud, Amazon Redshift uses hardware accelerated SSL to communicate with Amazon S3 or Amazon DynamoDB for COPY, UNLOAD, backup, and restore operations.

Please note that all the channels are secured by default and do not require any additional configuration on your part, as explained below:

2. Between Replicate server and CloudBeam AMI in EC2 (secured channel by default)[Reza] Correct, this is secured using the AES 256 bit SSL encryption

3. Between CloudBeam AMI and S3 (Secured by default)[Reza] Correct, The files are actually only passing through the ACB AMI in memory and are written to the S3 bucket with the Server Side Encryption enabled by default. These data files never get written to the disks of the ACB AMI.

4. Between S3 and Reshift (Secured by default)[Reza] Correct, since server side encryption is enabled on the Data Files in S3, the COPY commandused to load the Data from S3 to Redshift supports the use of AWS managed encryption keys (SSE). To protect your data in transit within the AWS cloud, Amazon Redshift uses hardware accelerated SSL to communicate with Amazon S3 or Amazon DynamoDB for COPY, UNLOAD, backup, and restore operations.

1. If the target is not Redshift. Still the line is encrypted by default or do I need to do anything specific to secure the line.

2. Could you please point me to any of Attunity technical documentation which convey this feature since I need to convey the security in Attunity to the potential client.

Thanks again,
rp

Hello Ram,

If your target is RDS MySQL then you would need Two Replicate Server.
The configuration would require One Replicate Server on Premise for your source to transfer the data to anther Replicate server on AWS and that transfer to the RDS MySQL.

The transfer between the two Repicate server would be using Attunity File Transfer Service:

When using the File Transfer Service, file-channel files are always transferred over an
encrypted session.

The session is encrypted as follows:
The client and server create an AES-256 session key using the Diffie-Hellman key
exchange protocol (using the OpenSSL library). After the key is created, all file
transfers between the client and the server will take place over a secure and encrypted
communication channel.
However, even though the session is encrypted, communication between the client
and the server may still be susceptible to man-in-the-middle attacks. A
man-in-the-middle in possession of the session key would be able to intercept any data
transferred between the client and the server.
To eliminate man-in-the-middle attacks, a "shared password" needs to be provided
when configuring the local and remote file channel endpoints. Once the session is
established, both the client and the serveruse the shared password to re-key the
session key during the next packet exchange, thereby preventing the original session
key from being used for man-in-the-middle attacks.

To sum up:
1. Strong encryption is used regardless of whether a password was provided.
2. Providing a password eliminates the risk of a man-in-the-middle attack.

If your target is RDS MySQL then you would need Two Replicate Server.
The configuration would require One Replicate Server on Premise for your source to transfer the data to anther Replicate server on AWS and that transfer to the RDS MySQL.

The transfer between the two Repicate server would be using Attunity File Transfer Service:

When using the File Transfer Service, file-channel files are always transferred over an
encrypted session.

The session is encrypted as follows:
The client and server create an AES-256 session key using the Diffie-Hellman key
exchange protocol (using the OpenSSL library). After the key is created, all file
transfers between the client and the server will take place over a secure and encrypted
communication channel.
However, even though the session is encrypted, communication between the client
and the server may still be susceptible to man-in-the-middle attacks. A
man-in-the-middle in possession of the session key would be able to intercept any data
transferred between the client and the server.
To eliminate man-in-the-middle attacks, a "shared password" needs to be provided
when configuring the local and remote file channel endpoints. Once the session is
established, both the client and the serveruse the shared password to re-key the
session key during the next packet exchange, thereby preventing the original session
key from being used for man-in-the-middle attacks.

To sum up:
1. Strong encryption is used regardless of whether a password was provided.
2. Providing a password eliminates the risk of a man-in-the-middle attack.

Thanks,
Steve

Hi Steve,

Thanks for the information and understood from your explanation that how security enforced between attunity server.

Can you please let me know how the security work between the second Replicate server in AWS and RDS? is it encrypted and secured by default without any additional out of the box configuration?