A maioria das aplicações web hoje exige pelo menos alguma estratégia básica de segurança. Por exemplo, sites que oferecem conteúdo protegido por senha, sites com apenas um back-end de administrador, blogs e revistas pessoais, sites de comércio eletrônico, intranets corporativas e assim por diante.
A abordagem de design mais comum para construir esses tipos de aplicativos Web é integrar a política de segurança à lógica de negócios do aplicativo Web, onde o aplicativo determina se um usuário tem permissão para acessar determinados dados no banco de dados. Neste cenário, a função do banco de dados é simplesmente armazenar dados e servi-los mediante solicitação. Em outras palavras, se uma aplicação web comanda o banco de dados para fornecer informações específicas, o banco de dados executa o comando diretamente, sem verificar as permissões do usuário.
Neste artigo, você aprenderá como aproveitar os recursos de segurança integrados da Oracle para impor regras de segurança de aplicativos no nível do banco de dados para melhorar a segurança geral de seu aplicativo. Como benefício colateral, proteger o acesso aos dados diretamente no banco de dados não apenas melhora a segurança dos aplicativos, mas também ajuda a reduzir a complexidade.
E quantoà necessidade de segurança do lado do banco de dados
para controlar o acesso aos dados de aplicativos da web? Na maioria dos casos não há problema; esta é uma boa solução, especialmente se os dados envolvidos não forem de missão crítica ou ultrassecretos. Este método é usado em muitos livros e recursos online. Na verdade, um livro popular sobre PHP/MySQL desencoraja explicitamente a criação de mais de uma conta de usuário de banco de dados por aplicativo porque “usuários adicionais ou permissões complexas podem exigir mais verificações antes de prosseguir com as informações e diminuir a velocidade de execução do MySQL”. Isso é verdade; no entanto, há algumas coisas que você pode querer considerar antes de desistir da ideia de integrar a segurança à lógica do seu banco de dados. Vejamos o exemplo a seguir.
Digamos que você crie um sistema de gerenciamento de conteúdo (CMS). Um banco de dados é usado para armazenar o conteúdo publicado no site. A maioria dos dados é pública, permitindo que usuários anônimos da web os leiam; Use uma única conta de banco de dados para acessar e modificar registros no banco de dados e controle a segurança com código PHP protegendo com senha o acesso a páginas exclusivas de administrador.
Se o lado público de uma aplicação web sofrer um ataque como a injeção de SQL em um formulário de pesquisa pública (ou seja, um formulário que não esteja suficientemente codificado), o invasor poderá executar instruções SQL arbitrárias em objetos de banco de dados que o conta pública tem acesso. É claro que, neste caso, executar a instrução SELECT não representa um grande problema porque os dados são públicos. Mas como os direitos públicos e administrativos usam a mesma conta de banco de dados, o invasor também pode executar instruções UPDATE e DELETE, ou até mesmo excluir tabelas do banco de dados.
Como podemos evitar que isso aconteça? O método mais simples é restringir completamente as permissões da conta do banco de dados público para modificar dados. Vamos dar uma olhada em como a Oracle resolve esse problema.
Visão Geral Básica da Segurança Oracle
O Oracle Database fornece aos desenvolvedores Web muitas maneiras de controlar o acesso aos dados, desde o gerenciamento do acesso a objetos específicos do banco de dados, como tabelas, visualizações e procedimentos, até o controle do acesso aos dados em linhas ou colunas individuais. Obviamente, uma discussão sobre todos os recursos ou opções de segurança disponíveis no Oracle está além do escopo deste artigo. Aqui não entraremos em muitos detalhes, mas apenas nos aspectos mais básicos da segurança de acesso a dados Oracle:
· Autenticação e contas de usuário · Permissões ·
Autenticação de função e contas de usuário. Tal como acontece com outros bancos de dados, cada usuário (conta de banco de dados) que solicita acesso ao Oracle deve ser autenticado. A validação pode ser feita por um banco de dados, sistema operacional ou serviço de rede. Além da autenticação básica (autenticação por senha), a Oracle também oferece suporte a mecanismos de autenticação fortes, como Kerberos, CyberSafe, RADIUS e assim por diante.
Papel. Uma função Oracle é um conjunto nomeado de permissões. Embora você possa conceder permissões de conta de usuário diretamente, o uso de funções pode simplificar bastante o gerenciamento de usuários, especialmente quando você precisa gerenciar um grande número de usuários. É muito eficiente criar funções pequenas e gerenciáveis e depois conceder aos usuários uma ou mais funções com base no seu nível de segurança. Sem mencionar como é fácil modificar permissões – basta modificar a função à qual a função está associada, em vez de modificar cada conta de usuário.
Para simplificar o trabalho inicial de criação de novos usuários, o Oracle vem com três funções predefinidas:
· Função CONNECT - Esta função permite que os usuários se conectem ao banco de dados e executem operações básicas, como criar suas próprias tabelas. Por padrão, esta função não pode acessar tabelas de outros usuários.
·Função RESOURCE - A função RESOURCE é semelhante à função CONNECT, mas permite que os usuários tenham mais permissões de sistema, como criação de gatilhos ou procedimentos armazenados.
·Função DBA – permite que o usuário tenha todos os privilégios do sistema.
Autorizações e permissões em uso
Nesta seção, discutimos como usar as autorizações e permissões da Oracle para melhorar a segurança do exemplo simples de CMS discutido no início deste artigo. Supõe-se que o conteúdo fornecido aos usuários da aplicação esteja armazenado na tabela WEB_CONTENT.
Primeiro, crie a tabela. Inicie o Oracle Database Special Edition e faça login como administrador do sistema. Libere o usuário de RH de amostra se ele ainda não tiver sido liberado. Siga as instruções no Guia de primeiros passos incluído na instalação da Edição Especial. Observe que, por padrão, os usuários de RH recebem a função RESOURCE. Aqui, atribua ao usuário a função de DBA para que a conta possa ser usada para gerenciar os aspectos de banco de dados do aplicativo CMS. É claro que a conta de usuário do RH não será utilizada para acesso online, apenas para administração de banco de dados.
Agora você pode criar uma nova tabela usando o Navegador de Objetos ou executando a janela Comandos SQL. Aqui está o código para criar a tabela:
CREATE TABLE WEB_CONTENT (
page_id NÚMERO CHAVE PRIMÁRIA,
conteúdo_da_página VARCHAR2(255)
);
Como a tabela foi criada usando a conta de usuário HR, a tabela pertence à conta HR e está no esquema HR, e outros usuários não poderão acessar a tabela até que recebam explicitamente permissão para acessá-la. Se você não acredita, você pode criar um novo usuário e tentar usar esse usuário para acessar a tabela WEB_CONTENT.
Agora crie dois novos usuários, CMS_USER e CMS_EDITOR. Finalmente, CMS_USER receberá permissões somente leitura na tabela WEB_CONTENT e esse usuário será usado como a conta do banco de dados que fornece conteúdo como um usuário anônimo da Web. A conta CMS_EDITOR terá mais permissões na tabela e será usada como conta do editor CMS (a conta necessária para alterar e manter os dados na tabela).
Novos usuários podem ser criados utilizando a interface gráfica do XE ou executando o seguinte comando:
CREATE USER cms_user IDENTIFIED BY cms_user;
CRIAR USUÁRIO cms_editor IDENTIFICADO POR cms_editor;
(Para simplificar, a senha aqui corresponde ao nome de usuário.)
Para que ambas as contas façam login no banco de dados, precisamos atribuir a elas a função CONNECT. Para fazer isso, marque a caixa de seleção CONNECT em Informações do usuário na seção Administração/Usuários do banco de dados da interface gráfica do XE ou execute o seguinte comando:
GRANT CONNECT to cms_user;
GRANT CONNECT to cms_editor
Agora, se você tentar fazer login como usuário CMS_USER ou CMS_EDITOR e tentar ler dados da tabela WEB_CONTENT (selecione * em hr.web_content;), encontrará o seguinte erro:
ORA-00942: tabela ou visualização não
existe Para acessar os dados ou apenas ver a tabela, você precisa conceder às contas CMS_USER e CMS_EDITOR permissões somente leitura na tabela WEB_CONTENT:
GRANT SELECT em hr.web_content para cms_user;
GRANT SELECT em hr.web_content para cms_editor;
O código acima permite que essas duas contas executem instruções SELECT na tabela WEB_CONTENT. Se você tentar executar outras instruções, encontrará um erro. Por exemplo, inserir uma linha:
INSERT INTO hr.web_content (page_id,page_content) VALUES (1,'hello world');
produzirá a mensagem de erro
ORA-01031: privilégios insuficientes
para permitir que o CMS_EDITOR altere o conteúdo desta tabela, as seguintes permissões precisam ser concedidas:
GRANT INSERT,UPDATE,DELETE em hr.web_content para cms_editor;
De agora em diante, a conta CMS_EDITOR pode executar instruções INSERT, UPDATE e DELETE na tabela WEB_CONTENT.
Veja como é fácil! Pode-se observar que gerenciar permissões por meio de funções é um método mais eficaz. Caso o banco de dados Oracle utilizado não seja XE, pode-se realizar as seguintes operações:
Criar uma role:
CREATE ROLE leitor;
CREATE ROLE escritor;
Conceder permissões de função:
GRANT SELECT ON web_content TO leitor;
GRANT INSERT, UPDATE, DELETE ON web_content TO escritor;
Dê função ao usuário:
GRANT leitor TO cms_user;
GRANT leitor TO cms_editor (eles também precisam ler)
GRANT escritor TO cms_editor
Observe que se você alterar a definição da função READER, essas alterações afetarão todas as contas de usuário com essa função. Se as permissões forem concedidas diretamente aos usuários, cada conta de usuário deverá ser atualizada individualmente.
Depois de concluir as etapas acima, você poderá configurar seu aplicativo PHP para usar a conta CMS_USER para todas as conexões de banco de dados solicitadas por usuários anônimos da Web e a conta CMS_EDITOR para conexões iniciadas por páginas administrativas protegidas por senha. Agora, mesmo que um formulário web público seja comprometido, o impacto no banco de dados será mínimo porque a conta CMS_USER possui apenas permissões somente leitura.
Conclusão
Neste artigo, apresentamos apenas brevemente alguns dos recursos mais básicos da segurança de acesso a dados Oracle. Além disso, a Oracle possui muitos outros recursos que elevam a segurança de seus aplicativos Web para o próximo nível, incluindo Virtual Private Database (VPD) e segurança de tags.