Neste artigo vamos falar sobre as quotas dos usuários nas tablespaces. Qual o espaço que um usuário pode usar em uma tablespace? Em quais tablespaces um usuário pode criar objetos? As respostas a estas perguntas dependem das quotas disponíveis para o usuário nas tablespaces.
Definição de quotas
A quota que um usuário tem em uma tablespace pode ser definida na criação do usuário ou após a sua criação.
Para definir a quota no momento da criação do usuário, basta adicionar uma cláusula do tipo:
QUOTA <tamnho> ON <nome_tablespace>
Por exemplo, vamos criar um usuário com quota de 12Mb em uma tablespace.
CREATE USER usr_1 IDENTIFIED BY senha_usr_1
DEFAULT TABLESPACE tabs1
TEMPORARY TABLESPACE temp
QUOTA 12M ON tbs_1;
Obs.: Podem ser adicionadas múltiplas cláusulas QUOTA, para definir quotas em várias tablespaces.
Para alterar a quota do usuário de 12Mb para 20Mb, teríamos:
ALTER USER usr_1 QUOTA 20M ON tbs_1;Isso limitaria o usuário usr_1 a criar objetos como tabelas, índices e views materializadas até o limite de 12Mb, de acordo com a criação (CREATE USER .. acima), ou 20Mb após a alteração (ALTER USER .. acima) na tablespace tbs_1.
O comando abaixo pode ajudar a verificar quanto cada usuário está usando nas tablespaces e quais as quotas.
select username, tablespace_name,
bytes/1024/1024 usado_MB,
max_bytes/1024/1024 quota_Mb
from dba_ts_quotas
order by username;
Uma particularidade na análise do retorno destas informações é quanto ao valor -0,000 (ou algo do tipo). Este valor 'zero negativo' diz respeito à quota ilimitada (UNLIMITED QUOTA) na respectiva tablespace. São estes casos que merecem atenção especial. Um usuário pode receber quota ilimitada em uma tablespace no momento de sua criação ou após. Por exemplo, na criação teríamos:
CREATE USER usr_2 IDENTIFIED BY senha_usr_2
DEFAULT TABLESPACE tabs2
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON tbs_2;
E após a criação, caso a cláusula QUOTA UNLIMITED ON tbs_2 não tivesse sido usada no momento da criação do usuário, por meio de um ALTER USER, teríamos:
ALTER USER usr_2 QUOTA UNLIMITED ON tbs_2;Segurança
Este ato pode ter implicações de segurança. Se um usuário 'normal' tiver quota ilimitada em uma tablespace crítica, este usuário pode comprometer todo o espaço da tablespace, o que está relacionado a um ataque de 'negação de serviço'. O risco mais sério é o privilégio de sistema UNLIMITED TABLESPACE, que permite que um usuário tenha quota ilimitada em TODAS as tablespaces que não possuem quotas específicas e explícitas concedidas para o usuário em questão.
Quando falamos em TODAS as tablespaces estamos falando, inclusive, da tablespace SYSTEM, permitindo que sejam criados objetos do usuário nesta tablespace, o que pode comprometer todo o banco e não só as aplicações dependentes de uma tablespace específica. Nem precisamos nem dizer que isso não é nada bom.
Checagens
Bem, vamos tentar arrumar as coisas, então. Primeiro, podemos verificar se existem definições explícitas de quota para algum usuário na tablespace SYSTEM.
select
username,
bytes/1024/1024 used,
max_bytes/1024/1024 quota
from dba_ts_quotas
where tablespace_name = 'SYSTEM'
order by username;
Se este comando retornar alguma linha, então é necessário uma avaliação mais detalhada para verificar a possibilidade de revogar a quota.
O próximo passo é verificar a existência usuários com o privilégio de sistema UNLIMITED TABLESPACE.
select grantee
from dba_sys_privs
where privilege = 'UNLIMITED TABLESPACE';
O retorno deste comando deve ser cuidadosamente avaliado pois, como já mencionamos anteriormente, este privilégio também inclui a tablespace SYSTEM.
Minimizando riscos
Após identificarmos todos os usuários e suas quotas nas tablespaces, a próxima tarefa é minimizar os riscos. Podemos fazer isso removendo a quota ilimitada da tablespace SYSTEM e assegurando que a quota na tablespace SYSTEM seja 0 (zero) para todos os usuários. Isso pode ser feito sem maiores impactos nas aplicações, apenas tomando o cuidado de garantirmos que não há nenhum objeto na tablespace SYSTEM pertencente a um outro schema, diferente do SYSTEM.
Para verificar isso, podemos utilizar o seguinte comando:
select owner, segment_type, segment_name
from dba_segments
where tablespace_name = 'SYSTEM'
and owner not in ('SYS','SYSTEM');
O retorno deste comando pode trazer, normalmente, usuários como SYSTEM, SYS, OUTLN ou até LBACSYS (Label Security). Mas, se a lista trouxer outros usuários, estes precisam ser analisados com mais rigor e verificar a viabilidade de mover os objetos para as devidas tablespaces, diferentes da SYSTEM, e alterar os usuários também para uma tablespace default diferente de SYSTEM. Para alterar a tablespace default de um usuário deve ser usado o seguinte comando:
alter user usr_1 default tablespace tbs_2;E para mover uma tabela de uma tablespace para outra, usamos:
alter table usr_1.tb_1 move tablespace tbs_2;Observações
- Os índices das tabelas movidas para outra tablespace serão alterados para UNUSABLE, sendo necessário reconstrui-los (alter index .. rebuild).
- Os rowids serão alterados devido à alteração da localização física. Com isso, caso haja aplicações baseadas no rowid, elas precisarão ser revisadas também.
- Algumas procedures dependentes também podem ser invalidadas.
As duas razões prováveis que levam um usuário a ter o privilégio UNLIMITED TABLESPACE são a atribuição direta, na criação ou alteração do usuário, ou então, em versões anteriores a 10g, através da role RESOURCE. Na versão 10g, a role RESOURCE não traz o privilégio UNLIMITED TABLESPACE embutido, como na versão 9i, por exemplo.
Para constatar isso, pode ser utilizado o seguinte comando:
select *
from dba_sys_privs
where grantee = 'RESOURCE';
Finalizando
Bem, tentamos traçar aqui um plano para uma política de quotas de usuários nas tablespaces que traga uma segurança maior ao sistema. Lógico que todas as alterações devem ser testadas e, na medida do possível, otimizadas para cada ambiente, antes de ser implementada nos bancos de produção. Um abraço a todos e até o próximo artigo, ainda tratando de outros aspectos básicos de segurança de ‘infra-estrutura’ em bancos de dados Oracle.
