Assumptions:
- you're referring to ASE's column-level encryption which requires a user/role to have
decrypt
permissions to see the actual data (as opposed to database-level encryption which merely encrypts the data out on disk)
ASE encrypted data is replicated as varbinary; this means that at no time is the data decrypted and/or re-encrypted; of course, it also means you need a copy of the encryption key in the RDS.
NOTE: If using a MSA or Warm Standby setup you can replicate the encryption key(s) to the RDB.
NOTE: If you have the wrong encryption key in the RDS, that varbinary(X)
data will not be decryptable ("Duh, Mark!" ?).
If you're creating explicit repdefs for the table then you'll need to designate the encrypted column's datatype as varbinary(X)
, where X
is the value you'll find in the associated (PDB) syscolumns.encrlen
column.
The default function string class is already configured with a function/function-string that supports replication of encrypted data; this basically consists of issuing set ciphertext on
when the DSI connects to the RDB, thus allowing that varbinary(X)
data to be written directly into an encrypted column.
Permissions to write the varbinary(X)
data into the RDB table should be the same as for any write operation into the table.
As for replication of encrypted data in a heterogenous environment ... I'm about 98% sure this isn't possible if simply because each RDBMS product, if it supports some sort of column-level encryption, uses different encryption methods and keys. [I'd have to peruse the latest SRS 16.x manuals if this has changed with recent versions of the product.]