O uso de procedimentos Oracle PL/SQL para controlar o acesso a dados é frequentemente enfatizado em livros de PL/SQL e outras fontes como sendo uma abordagem mais segura. Já vi vários sistemas onde toda a lógica de negócio relacionada com dados é realizada através de pacotes, procedures e funções, por isso o código da aplicação torna-se bastante "burro" e fica apenas responsável pela parte de visualização. Eu até ouvi alguns desenvolvedores chamarem essas abordagens e arquitetos de direção de nazis do banco de dados :) porque todo o código lógico reside no banco de dados. Eu sei sobre os benefícios de desempenho do procedimento de banco de dados, mas agora estou interessado em uma "melhor segurança" ao usar o modelo de cliente grosso e os procedimentos de banco de dados. Presumo que esse design seja usado principalmente quando bancos de dados Oracle (e talvez MS SQL Server) são usados.
Eu concordo que tal abordagem melhora a segurança, mas apenas se não houver muitos usuários e cada usuário do sistema tiver uma conta de banco de dados, então podemos controlar e monitorar o acesso aos dados por meio da segurança padrão do usuário do banco de dados. No entanto, como tal abordagem aumenta a segurança para um sistema web médio onde o modelo de cliente grosso é usado: por exemplo, um usuário de banco de dados com concessões DML em todas as tabelas e outros usuários são tratados usando tabelas "users" e "user_rights"? Poderíamos usar procedimentos de banco de dados, salvar nomes de usuário no uso de contexto para filtragem, mas a vulnerabilidade reside na raiz - se a conta do banco de dados principal estiver comprometida, nada ajudará. É claro que em um sistema real podemos considerar pelo menos vários usuários principais (por exemplo frontend_db_user, backend_db_user).
Então, o uso de procedimentos armazenados pl/sql (todas as operações DML por meio de procedimentos) ajuda a aumentar a segurança em sistemas de modelo de cliente grosso (sistemas da web)?
A teoria por trás do uso de procedimentos armazenados para aumentar a segurança é que você não fornece acesso DML diretamente aos usuários . A ideia é que os usuários nunca obtenham nada além de permissões de execução nos procedimentos. Há também uma versão um pouco menos paranóica dessa abordagem, em que todas as gravações são feitas por procedimentos armazenados, mas as leituras de tabela/visualização podem ser feitas pelos usuários.
O raciocínio é que, se os usuários tiverem apenas permissões de execução em procedimentos armazenados e nenhum DML direto em tabelas ou exibições, eles não poderão manipular dados de maneiras imprevisíveis.
Para dar um exemplo, digamos que você tenha um sistema de conta bancária e a única maneira de fazer uma transferência de fundos é por meio de um procedimento armazenado. . Se você permitisse acesso DML direto às tabelas base, uma conta comprometida poderia ser usada para receber dinheiro sem deixar um rastro de auditoria.
Você está certo ao dizer que uma conta comprometida ainda é uma grande falha de segurança - grande o suficiente para passar por um caminhão. Se todo o acesso da conta comprometida for restrito à execução do procedimento armazenado, no entanto, pelo menos o buraco caberá apenas em um caminhão menor.