Segurança em aplicações web

vonlinkerstain:

Olá pessoal tudo bem?
Estamos iniciando um projeto aqui onde eu trabalho, e temos como objetivo colocarmos o nosso estoque online, para que os representantes consigam realizar vendas sem nos consultar.
Iremos implementar um ERP em j2ee usando session beans, e eu gostaria de colocar o estoque em um toncat com o JSP.

Gostaria de saber como é que fica a seguraça dos meus dados?
Devo separar o banco, e deixar somente o banco de estoque no servidor web, ou deixar o meu servidor de dados completo, e restringir o acesso do servidor web apenas a parte de estoque (é possível fazer isto?)

Abraços
Dirceu Semighini Filho

Já que você está usando session beans + web components, o ideal seria usar a segurança do J2EE através do JAAS para autenticação e autorização, pois dessa maneira vc facilmente restringe acesso a determinados métodos do seu ejb ou na própria classe atavés das roles do usuário logado, como também acesso a recursos web.

Vocês vão usar JBoss ou algum AS pago ?

Eu não me lembro em qual edição, mas a pouco tempo saiu uma reportagem na Javamagazine sobre segurança no J2EE usando o JAAS e configurando o mesmo no JBoss.

[]s

Douglas

JBoss

Os custos aqui serao os menores possiveis…

Fizeram uma proposta de armazenarmos o site em uma dataware house, e por isso eu fiz esta pergunda… Como sei que este negócio de segurança de apllicativos web e meio complicada…

Alem de usar o JAAS, sugiro que o sistema acesse uma réplica
da base, e não a base real. Principais motivos:

• Segurança: Seu servidor pode ficar numa DMZ e/ou um datacenter externo, limitando o impacto de uma eventual invasão;

• Performance: Vc. pode definir um modelo de dados otimizado para as consultas e alimentar a base em batch apenas com a informação necssária, a qual, tipicamente, é apenas um subconjunto de tudo que vc. terá no ERP.

psevestre:

Alem de usar o JAAS, sugiro que o sistema acesse uma réplica
da base, e não a base real. Principais motivos:

• Segurança: Seu servidor pode ficar numa DMZ e/ou um datacenter externo, limitando o impacto de uma eventual invasão;

• Performance: Vc. pode definir um modelo de dados otimizado para as consultas e alimentar a base em batch apenas com a informação necssária, a qual, tipicamente, é apenas um subconjunto de tudo que vc. terá no ERP.

Neste caso a replica ficaria no servidor de web?

Este negócio de segurança é muita responsabilidade. O meu principal problema é que a parte que estiver na internet, deve ter uma atualizaç/ao continua…

No servidor web ou em uma máquina acessível por este, mas que não o servidor principal.

Quanto à atualização contínua, é uma questão de custo x benefício.

Nesta hora o papel do analista é deixar claro para o usuário/cliente, o que significa a necessidade que ele apresenta.

Se os dados realmente são tão voláteis ao ponto de ser necessário acesso aos dados do “último commit”, isto terá influência decisiva na solução que será necessária.

Com uma relação consulta / atualização for próxima da unidade, e/ou se o custo de negócio associado a dar uma posição que pode não ser a atual justificar, possivelmente justifica-se o acesso direto ao ERP. De outra forma, uma arquitetura baseada em réplica dos dados deve atender.

é que aqui trabalhamos com produção em cima dos pedidos,
Vendas vai ficar na internet, e ai. Isto que ser online com o bd aqui… senão não tem como programar a produção, ou pior, encavalar pedidos…

vonlinkerstain:

é que aqui trabalhamos com produção em cima dos pedidos,
Vendas vai ficar na internet, e ai. Isto que ser online com o bd aqui… senão não tem como programar a produção, ou pior, encavalar pedidos…

Se vc. diz que seu processo é assim, sou obrigado a acreditar ;^)

Enfim, o ponto é que sempre vale questionar necessidades deste tipo. Com disse anteriormente, é uma questão custo x benefício que deve ser avaliada e entendida pelos patrocinadores do sistema.

Já participei do desenho de sistemas com necessidades semelhantes e, quase sempre, questões como esta puderam ser resolvidas através de processos batch que faziam o sincronismo dos dados.

Em um sistema de naterial promocional, p.ex, o sistema recebia quotas que cada revenda poderia solicitar sem necessidade de aprovação. Os pedidos eram consolidados diariamente e agrupados para otimizar os processos de compra e distribuição.

Em outros casos, o sistema era apenas um front-end para um conjunto de transações que foram desenvolvidas no ERP (SAP no caso). Esta , aliás, é uma alternativa que vc. deve considerar seriamente. Se, após todas as considerações voce chegar à conclusão que o acesso ao ERP deve ser online, faça o desenho do sistema de forma que não exista necessidade de acesso direto às tabelas do banco, nem mesmo pelos SessionBeans !

Olha cara, isto que voce esta me falando é tudo novo pra mim.
Principalmente esta idéia de deixar um servidor de bd externo. Eu sou meio contra isto, mas não tenho argumentos. É mais gosto e opnião pessoal mesmo.
Sei que cuidar de segurnaça em um servidor web é coisa feia e de uma responsabilidade muito grande.
Quem toma as decisões aqui sou eu, e eu tenho muito receio de escolher uma empresa que não seja assim tão segura quanto se pensa, pois eu mesmo já vi vários provedores com Linux, se dizendo seguros, mas utilizando versões de apache e CIA muito antigas e com falhas de segurnaça.

Talvez ai resida o meu medo/receio.

Por que não deveria fazer nem os session bean acessar os dados diretamente?
Deveria deixar um servidor de aplicativos separado de um servidor de dados?

Eu sou (quase totalmente) contra a ter os serviços e máquinas fora da empresa. Aqui no cliente é outsourcing total e é bem improdutivo, burocrático e chato.

Olhando do ponto de vista de segurança, não há diferença entre ter um
banco de dados local com apenas as informações relevantes e ter acesso ao banco remoto. Se alguem invadir o servidor, os dados estão espostos da mesma maneira.

Na prática, o acesso remoto ao servidor tende a ser mais arriscado. É muito mais prático para o DBA simplesmente criar um login de aplicação com acesso irrestrito às tabelas…

Custo x Benefício, de novo. Segurança custa caro. A IBM, p.ex., vende um serviço de “hacker ético” que faz avaliações periódicas do seu site, tentando invadí-lo.

Para ter um nível a mais de segurança. Use o session bean apenas como um wrapper de uma stored procedure (ou o equivalente disto no seu ERP) que retorna os dados necessários.

Depende… Tente estimar os dados a manipular nos cenários típicos e faça o desenho de forma a minimizar “round-trips”.

Agora acho que entendi…

O session bean so retornará os dados necessários, quem os classifica é a stored procedure, certo.
Vou criar um bd separado apenas para as tabelas de requisição de compra online…