Get Data Moving 1
Results 1 to 10 of 10

Thread: SSL settings in Attunity cloudbeam for amazon redshift

  1. #1
    ram
    ram is offline Junior Member
    Join Date
    Jan 2015
    Posts
    23
    Rep Power
    0

    SSL settings in Attunity cloudbeam for amazon redshift

    Where to do security SSL settings in Attunity
    Cloudbeam for Amazon redshift.

  2. #2
    reza.khan is offline Junior Member
    Join Date
    Jun 2013
    Posts
    25
    Rep Power
    0
    Hi Ram,

    Thank you for contacting technical support.

    No additional user configuration is required to enable or disable the security settings in Attunity Cloudbeam for Amazon Redshift. The architecture of the solution enables SSL encryption by default.

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

    Thank you.

    Reza K

  3. #3
    ram
    ram is offline Junior Member
    Join Date
    Jan 2015
    Posts
    23
    Rep Power
    0
    Hi Reza,

    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

    OTE=reza.khan;5445]Hi Ram,

    Thank you for contacting technical support.

    No additional user configuration is required to enable or disable the security settings in Attunity Cloudbeam for Amazon Redshift. The architecture of the solution enables SSL encryption by default.

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

    Thank you.

    Reza K[/QUOTE]

  4. #4
    reza.khan is offline Junior Member
    Join Date
    Jun 2013
    Posts
    25
    Rep Power
    0
    Quote Originally Posted by ram View Post
    Hi Reza,

    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.

    Thank you.

    Reza K

  5. #5
    rameshpachamuthu is offline Junior Member
    Join Date
    Mar 2015
    Posts
    19
    Rep Power
    0
    Quote Originally Posted by reza.khan View Post
    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.

    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.

    Regards,
    RP

  6. #6
    reza.khan is offline Junior Member
    Join Date
    Jun 2013
    Posts
    25
    Rep Power
    0
    Quote Originally Posted by rameshpachamuthu View Post
    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.

    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 see these following AWS posts:
    Loading Encrypted Data Files from Amazon S3 - Amazon Redshift
    Amazon Redshift Security Overview - Amazon Redshift

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

    Thank you.

    Reza K

  7. #7
    rameshpachamuthu is offline Junior Member
    Join Date
    Mar 2015
    Posts
    19
    Rep Power
    0
    Quote Originally Posted by reza.khan View Post
    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 see these following AWS posts:
    Loading Encrypted Data Files from Amazon S3 - Amazon Redshift
    Amazon Redshift Security Overview - Amazon Redshift

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

    Thank you.

    Reza K

    Thanks Reza for your clear explanation.

    Just few more queries. What about if I use RDS MySQL as target.

    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

  8. #8
    stevenguyen is offline Senior Member
    Join Date
    May 2014
    Posts
    299
    Rep Power
    6
    Quote Originally Posted by rameshpachamuthu View Post
    Thanks Reza for your clear explanation.

    Just few more queries. What about if I use RDS MySQL as target.

    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.

    See more information below:
    Attunity CloudBeam for Amazon RDS | Attunity


    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

  9. #9
    rameshpachamuthu is offline Junior Member
    Join Date
    Mar 2015
    Posts
    19
    Rep Power
    0
    Quote Originally Posted by stevenguyen View Post
    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.

    See more information below:
    Attunity CloudBeam for Amazon RDS | Attunity


    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?

    Thanks,
    RP
    Last edited by rameshpachamuthu; 04-29-2015 at 02:40 AM.

  10. #10
    stevenguyen is offline Senior Member
    Join Date
    May 2014
    Posts
    299
    Rep Power
    6
    Quote Originally Posted by rameshpachamuthu View Post
    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?

    Thanks,
    RP
    Hello Ram,

    Since data going from Attunity Replicate to the RDS database (Oracle / SQL / MySQL) using the native client (ssl enforced using odbc property manually).

    Thanks,
    Steve

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •