Trabalhar com um banco de dados Oracle usando a extensão oracle_fdw
Para acessar um banco de dados Oracle pelo cluster de banco de dados do Aurora PostgreSQL , você pode instalar e usar a extensão oracle_fdw
. Essa extensão é um invólucro de dados externos para bancos de dados Oracle. Para saber mais sobre a extensão, consulte a documentação do oracle_fdw
A extensão oracle_fdw
é compatível com o Aurora PostgreSQL 12.7 (Amazon Aurora versão 4.2) e versões posteriores.
Tópicos
Ativação da extensão oracle_fdw
Para usar a extensão oracle_fdw, realize o procedimento a seguir.
Para ativar a extensão oracle_fdw
-
Execute o comando a seguir usando uma conta que tenha as permissões de
rds_superuser
.CREATE EXTENSION oracle_fdw;
Exemplo: usar um servidor externo vinculado a um banco de dados Amazon RDS for Oracle
O exemplo a seguir mostra o uso de um servidor externo vinculado a um banco de dados Amazon RDS for Oracle.
Para criar um servidor externo vinculado a um banco de dados do RDS for Oracle
-
Na instância de banco de dados do RDS for Oracle, observe:
-
Endpoint
-
Port
-
Database name
-
-
Crie um servidor externo.
test=>
CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//
endpoint
:port
/DB_name
');CREATE SERVER
-
Conceda uso a um usuário que não tenha privilégios
rds_superuser
, por exemplouser1
.test=>
GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
-
Conecte-se como
user1
e crie um mapeamento para um usuário Oracle.test=>
CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user '
oracleuser'
, password 'mypassword'
);CREATE USER MAPPING
-
Crie uma tabela estrangeira vinculada a uma tabela Oracle.
test=>
CREATE FOREIGN TABLE
mytab
(a int) SERVER oradb OPTIONS (table 'MYTABLE'
);CREATE FOREIGN TABLE
-
Consulte a tabela externa.
test=>
SELECT * FROM mytab;
a --- 1 (1 row)
Se a consulta relatar o seguinte erro, verifique seu grupo de segurança e a lista de controle de acesso (ACL) para verificar se as duas instâncias podem se comunicar.
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
Como trabalhar com criptografia em trânsito
A criptografia PostgreSQL-to-Oracle em trânsito é baseada em uma combinação de parâmetros de configuração de cliente e servidor. Para obter um exemplo usando o Oracle 21c, consulte About the Values for Negotiating Encryption and IntegrityACCEPTED
, portanto a criptografia depende da configuração do servidor de banco de dados do Oracle.
Se o banco de dados estiver no RDS for Oracle, consulte Criptografia de rede nativa do Oracle para configurar a criptografia.
Noções básicas da visualização e das permissões de pg_user_mappings
O catálogo PostgreSQL pg_user_mapping
armazena o mapeamento de um usuário do Aurora PostgreSQL para o usuário em um servidor de dados externo (remoto). O acesso ao catálogo é restrito, mas você usa a visualização pg_user_mappings
para ver os mapeamentos. Veja a seguir um exemplo que mostra como as permissões se aplicam a um banco de dados Oracle de exemplo, mas essas informações se aplicam de forma mais geral a qualquer wrapper de dados externo.
Na saída a seguir, você pode encontrar funções e permissões mapeadas para três usuários de exemplo diferentes. Usuários eo rdssu1
e rdssu2
são membros da função rds_superuser
, e user1
não é. O exemplo usa o metacomando \du
do psql
para listar as funções existentes.
test=>
\du
List of roles Role name | Attributes | Member of -----------------+------------------------------------------------------------+------------------------------------------------------------- rdssu1 | | {rds_superuser} rdssu2 | | {rds_superuser} user1 | | {}
Todos os usuários, incluindo aqueles com privilégios rds_superuser
, têm permissão para visualizar seus próprios mapeamentos de usuário (umoptions
) na tabela pg_user_mappings
. Como mostrado no exemplo a seguir, quando rdssu1
tenta obter todos os mapeamentos do usuário, é gerado um erro, mesmo com privilégios rdssu1
rds_superuser
:
test=>
SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
Veja a seguir alguns exemplos:
test=>
SET SESSION AUTHORIZATION rdssu1;
SET
test=>
SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions -------+-------+---------+--------+------------+---------------------------------- 16414 | 16411 | oradb | 16412 | user1 | 16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd} 16424 | 16411 | oradb | 16422 | rdssu2 | (3 rows)
test=>
SET SESSION AUTHORIZATION rdssu2;
SET
test=>
SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions -------+-------+---------+--------+------------+---------------------------------- 16414 | 16411 | oradb | 16412 | user1 | 16423 | 16411 | oradb | 16421 | rdssu1 | 16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd} (3 rows)
test=>
SET SESSION AUTHORIZATION user1;
SET
test=>
SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions -------+-------+---------+--------+------------+-------------------------------- 16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd} 16423 | 16411 | oradb | 16421 | rdssu1 | 16424 | 16411 | oradb | 16422 | rdssu2 | (3 rows)
Devido às diferenças na implementação de information_schema._pg_user_mappings
e pg_catalog.pg_user_mappings
, um rds_superuser
criado manualmente requer outras permissões para visualizar senhas no pg_catalog.pg_user_mappings
.
Nenhuma permissão adicional é necessária para um rds_superuser
visualizar senhas no information_schema._pg_user_mappings
.
Usuários que não tenham a função rds_superuser
poderão visualizar senhas em pg_user_mappings
somente nas seguintes condições:
-
O usuário atual é o usuário que está sendo mapeado e é proprietário do servidor ou mantém o privilégio
USAGE
sobre ele. -
O usuário atual é o proprietário do servidor, e o mapeamento é para
PUBLIC
.