Blog
Como utilizar Oracle Data Guard híbrido sem licença Advanced Security
A segurança dos dados é uma prioridade essencial para organizações que armazenam informações críticas em banco de dados. No Oracle, a criptografia de dados usando TDE (Transparent Data Encryption) é uma ferramenta recomendada para garantir a proteção das informações, mas, por ser uma feature licenciada separadamente, muitos optam por não utilizá-la em ambientes on-premises devido ao custo adicional.
No entanto, em ambientes na Oracle Cloud Infrastructure (OCI), a dinâmica de segurança muda: devido a Oracle adotar um modelo de segurança compartilhada, onde tanto o cliente quanto o provedor têm responsabilidades sobre a proteção do ambiente, a Oracle disponibiliza na sua infraestrutura, bancos de dados na OCI com TDE ativado, incluindo criptografia para tablespaces, sem custo adicional.
Essa situação pode gerar desafios para organizações que mantêm ambientes híbridos, onde o ambiente de produção local não tem criptografia habilitada, mas o standby na OCI possui a criptografia habilitada.
Até pouco tempo atrás, era necessário realizar a criptografia de dados manualmente ao replicar para o standby OCI, com dados vindos do ambiente on-premise sem licenciamento, o que trazia complexidade e possíveis falhas de segurança.
A partir da versão 19.16, a Oracle oferece uma solução inovadora: a criptografia automática para dados replicados de ambientes on-premises não criptografados para ambientes OCI. Isso significa que os dados enviados sem criptografia são automaticamente criptografados ao chegar no standby na nuvem, permitindo uma replicação segura e simplificada, sem a necessidade da licença Advanced Security on-premise. Além disso, o processo inverso (switchover) também se torna viável, se tratando da questão de criptografia.
Primeiramente, vamos definir os parâmetros estáticos do TDE no banco de dados on-premise.
Para configurar esses parâmetros, vamos criar os diretórios e conceder as permissões necessárias:
[oracle@srvprod ~]$ mkdir -p /opt/oracle/dcs/commonstore/wallets/cdbprod/okv [oracle@srvprod ~]$ mkdir -p /opt/oracle/dcs/commonstore/wallets/cdbprod/tde [oracle@srvprod ~]$ mkdir -p /opt/oracle/dcs/commonstore/wallets/cdbprod/tde_seps [oracle@srvprod ~]$ mkdir -p /opt/oracle/dcs/commonstore/wallets/cdbprod/tls [oracle@srvprod ~]$ chown -R oracle.oinstall /opt/oracle/dcs/commonstore/wallets/ [oracle@srvprod ~]$ chmod -R 700 /opt/oracle/dcs/commonstore/wallets/
Com os diretórios criados, iremos seguir com as configurações no banco de dados:
[oracle@srvprod ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Mon Nov 4 08:38:11 2024 Version 19.24.0.0.0 Copyright (c) 1982, 2024, Oracle. All rights reserved. Connected to: Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.16.0.0.0 SQL> alter system set WALLET_ROOT='/opt/oracle/dcs/commonstore/wallets/cdbprod' scope=spfile; System altered. SQL> alter system set TABLESPACE_ENCRYPTION=DECRYPT_ONLY scope=spfile; System altered.
Com os parâmetros estáticos do TDE no banco de dados on-premise configurados, iremos configurar agora no standby:
[oracle@srvstandby ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Mon Nov 4 08:38:11 2024 Version 19.24.0.0.0 Copyright (c) 1982, 2024, Oracle. All rights reserved. Connected to: Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.16.0.0.0 SQL> alter system set WALLET_ROOT='/opt/oracle/dcs/commonstore/wallets/cdbprod' scope=spfile; System altered. SQL> alter system set TABLESPACE_ENCRYPTION=AUTO_ENABLE scope=spfile; System altered.
Podemos então reiniciar o banco de dados produtivo e o standby, para que os parâmetros que ajustamos sejam aplicados.
Agora, após ambos os ambientes terem sido reiniciados, vamos definir os parâmetros dinâmicos do TDE no banco de dados on-premise e no standby.
Primeiramente, no banco de dados de produção:
SQL> alter system set TDE_CONFIGURATION= "KEYSTORE_CONFIGURATION=FILE" scope=both; System altered.
E então no standby:
SQL> alter system set TDE_CONFIGURATION= "KEYSTORE_CONFIGURATION=FILE" scope=both; System altered.
Em seguida, criamos o wallet e configuramos a master key no ambiente primário:
SQL> administer key management create keystore from keystore identified by eximioti123; Key succeeded SQL> administer key management create keystore from keystore identified by eximioti123; Key succeeded SQL> administer key management create keystore from keystore identified by eximioti123; Key succeeded
Dessa forma, os wallets já estarão criados, conforme podemos verificar abaixo do diretório configurado no parâmetro WALLET_ROOT:
[oracle@srvprod ~]$ ls -l /opt/oracle/dcs/commonstore/wallets/cdbprod/tde/ cwallet.sso ewallet_2024102803233855.p12 ewallet.p12
Copie então, os wallets para o ambiente standby:
[oracle@srvprod ~]$ rsync -vpt /opt/oracle/dcs/commonstore/wallets/cdbprod/tde/* srvstandby:/opt/oracle/dcs/commonstore/wallets/cdbprod/tde/
Para simular, iremos criar uma tablespace no ambiente primário e veremos que ele estará criptografado no standby:
SQL> create tablespace teste_eximioti datafile size 50M; Tablespace created. SQL> create table teste_1 tablespace teste_eximioti as select * from dba_objects; Table created. SQL> select owner, count(*) from teste_eximioti group by owner order by 2 desc; OWNER COUNT(*) -------------------------------------------------------------------------------- ---------- SYS 54085 PUBLIC 11790 MDSYS 4516 XDB 1055 ORDSYS 990 SYSTEM 478 DVSYS 405 WMSYS 398 CTXSYS 398 ORDDATA 292 LBACSYS 243 GSMADMIN_INTERNAL 213 EXIMIOTI_TESTE 204 AUDSYS 72 DBSNMP 59 OLAPSYS 25 DVF 22 OJVMSYS 19 REMOTE_SCHEDULER_AGENT 13 ORDPLUGINS 10 OUTLN 10 ORACLE_OCM 8 DBSFWUSER 8 SI_INFORMTN_SCHEMA 8 APPQOSSYS 6 25 rows selected.
Agora, vamos verificar se existe alguma tablespace criptografada no ambiente primário:
SQL> select c.name as PDB_NAME, t.name as TBS_NAME, e. ENCRYPTIONALG as ALG, e.STATUS from v$tablespace t, v$encrypted_tablespaces e, v$containers# and e.con_id = t.con_id and e.con_id = c.con_id order by e.con_id, t.name; no rows selected
Como pudemos verificar, não existe.
Para validar se a replicação dos dados foi realizada com sucesso e essa tablespace está criptografada no standby, vamos conectar nele e executar a mesma consulta.
SQL> select c.name as CONTAINER_NAME, t.name as TBS_NAME, e. ENCRYPTIONALG as ALG, e.STATUS from v$tablespace t, v$encrypted_tablespaces e, v$containers c where e.ts# = t.ts# and e.con_id = t.con_id and e.con_id = c.con_id order by e.con_id, t.name; CONTAINER_NAME TBS_NAME ALG STATUS -------------------------------------------------------------------------------------------------------------------------------- ------------------------------ ------- ---------- CDB$ROOT TESTE_EXIMIOTI AES128 NORMAL
Funcionando! A replicação foi realizada e ao receber o dado não criptografado, o standby o criptografa.
Para garantir que todo o ambiente standby esteja criptografado, vamos parar a replicação e verificar as demais tablespaces do ambiente e então, criptografá-las.
SQL> alter database recover managed standby database cancel; Database altered. SQL> select ' alter database datafile '''||df.name||''' encrypt;' COMMAND from v$tablespace ts, v$datafile df where ts.ts# = df.ts# and df.con_id = sys_context('userenv', 'con_id') and ts.con_id = df.con_id and (ts.name not in ('SYSTEM', 'SYSAUX') and ts.name not in (select value from v$parameter where name = 'undo_tablespace')); COMMAND -------------------------------------------------------------------------------------------------------------------------------------------------------------------- alter database datafile '+DATA/CDBPROD/DATAFILE/users.418.1182457117' encrypt; SQL> alter database datafile '+DATA/CDBPROD/DATAFILE/users.418.1182457117' encrypt; Database altered. SQL> alter session set container = prod01; Session altered. SQL> select ' alter database datafile '''||df.name||''' encrypt;' COMMAND from v$tablespace ts, v$datafile df where ts.ts# = df.ts# and df.con_id = sys_context('userenv', 'con_id') and ts.con_id = df.con_id and (ts.name not in ('SYSTEM', 'SYSAUX') and ts.name not in (select value from v$parameter where name = 'undo_tablespace')); COMMAND -------------------------------------------------------------------------------------------------------------------------------------------------------------------- alter database datafile '+DATA/CDBPROD/985FB8D6D14BB7ABE0536C4AA8C01033/DATAFILE/users.416.1182457309' encrypt; alter database datafile '+DATA/CDBPROD/985FB8D6D14BB7ABE0536C4AA8C01033/DATAFILE/system.364.11824577812' encrypt; alter database datafile '+DATA/CDBPROD/985FB8D6D14BB7ABE0536C4AA8C01033/DATAFILE/sysaux.292.1182469415' encrypt; 3 rows selected. SQL> alter database datafile '+DATA/CDBPROD/985FB8D6D14BB7ABE0536C4AA8C01033/DATAFILE/users.416.1182457309' encrypt; Database altered SQL> alter database datafile '+DATA/CDBPROD/985FB8D6D14BB7ABE0536C4AA8C01033/DATAFILE/system.364.11824577812' encrypt; Database altered SQL> alter database datafile '+DATA/CDBPROD/985FB8D6D14BB7ABE0536C4AA8C01033/DATAFILE/sysaux.292.1182469415' encrypt; Database altered
Após os ajustes realizados, retornamos a replicação de dados:
SQL> alter database recover managed standby database nodelay disconnect from session; Database altered
SQL> select c.name as CONTAINER_NAME, t.name as TBS_NAME, e. ENCRYPTIONALG as ALG, e.STATUS from v$tablespace t, v$encrypted_tablespaces e, v$containers c where e.ts# = t.ts# and e.con_id = t.con_id and e.con_id = c.con_id order by e.con_id, t.name; CONTAINER_NAME TBS_NAME ALG STATUS -------------------------------------------------------------------------------------------------------------------------------- ------------------------------ ------- ---------- CDB$ROOT TESTE_EXIMIOTI AES128 NORMAL CDB$ROOT USERS AES128 NORMAL PROD01 SYSAUX AES128 NORMAL PROD01 SYSTEM AES128 NORMAL PROD01 USERS AES128 NORMAL
Agora, vamos simular um switchover fazendo com que o ambiente OCI se torne nosso produção e o on-premise passe a ser o standby:
[oracle@srvstandby ~]$ dgmgrl sys@DGCDBPROD DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Nov 4 13:58:47 2024 Version 19.16.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. Password: Connected to "dgcdbprod" Connected as SYSDBA. DGMGRL> switchover to dgcdbprod; Performing switchover NOW, please wait... New primary database "dgcdbprod" is opening... Operation requires start up of instance "cdbprod" on database "cdbprod" Starting instance "cdbprod"... Connected to an idle instance. ORACLE instance started. Connected to "cdbprod" Database mounted. Database opened. Switchover succeeded, new primary is "dgcdbprod" DGMGRL>
Podemos então recriar o a tablespace em nosso ambiente produtivo na OCI para validar se será criptografado:
SQL> drop tablespace teste_eximioti including contents and datafiles; Tablespace dropped. SQL> create tablespace teste_eximioti datafile size 50M; Tablespace created. SQL> create table teste_1 tablespace teste_eximioti as select * from dba_objects; Table created. SQL> select owner, count(*) from teste_eximioti group by owner order by 2 desc; OWNER COUNT(*) -------------------------------------------------------------------------------- ---------- SYS 54085 PUBLIC 11790 MDSYS 4516 XDB 1055 ORDSYS 990 SYSTEM 478 DVSYS 405 WMSYS 398 CTXSYS 398 ORDDATA 292 LBACSYS 243 GSMADMIN_INTERNAL 213 EXIMIOTI_TESTE 204 AUDSYS 72 DBSNMP 59 OLAPSYS 25 DVF 22 OJVMSYS 19 REMOTE_SCHEDULER_AGENT 13 ORDPLUGINS 10 OUTLN 10 ORACLE_OCM 8 DBSFWUSER 8 SI_INFORMTN_SCHEMA 8 APPQOSSYS 6 25 rows selected. SQL> select c.name as CONTAINER_NAME, t.name as TBS_NAME, e. ENCRYPTIONALG as ALG, e.STATUS from v$tablespace t, v$encrypted_tablespaces e, v$containers c where e.ts# = t.ts# and e.con_id = t.con_id and e.con_id = c.con_id order by e.con_id, t.name; CONTAINER_NAME TBS_NAME ALG STATUS -------------------------------------------------------------------------------------------------------------------------------- ------------------------------ ------- ---------- CDB$ROOT TESTE_EXIMIOTI AES128 NORMAL CDB$ROOT USERS AES128 NORMAL PROD01 SYSAUX AES128 NORMAL PROD01 SYSTEM AES128 NORMAL PROD01 USERS AES128 NORMAL
Validado no ambiente produtivo OCI, vamos verificar se foi replicado sem criptografia para o nosso ambiente standby on-premise:
SQL> select c.name as CONTAINER_NAME, t.name as TBS_NAME, e. ENCRYPTIONALG as ALG, e.STATUS from v$tablespace t, v$encrypted_tablespaces e, v$containers c where e.ts# = t.ts# and e.con_id = t.con_id and e.con_id = c.con_id order by e.con_id, t.name; no rows selected
Como vimos, configurar o ambiente com os parâmetros corretos, permite que o ambiente standby na OCI receba dados não criptografados e, automaticamente, aplique a criptografia, enquanto o ambiente on-premises permanece sem criptografia.
Além disso, validamos a capacidade de realizar um switchover mantendo a integridade dos dados e segurança na OCI, que é uma funcionalidade que proporciona maior flexibilidade e resiliência ao ambiente de disaster recovery (DR).
Portanto, com essa configuração correta, os clientes podem adotar um ambiente híbrido com maior confiança na segurança de seus dados, enquanto aproveitam a flexibilidade e os recursos oferecidos pela OCI.
152 visualizações
