Ah tah,
Sei que é uma MV, só não estava associando ao contexto, uma vez que quem as mencionou foi a Carol. O que eu menciono é que se o cliente tem acesso às configurações do ambiente não é interessante criar duas conexões no SC para gerenciar um DB externo, porque sempre ele terá acesso a esse DB.
O cliente tem acesso apenas ao banco de dados e só pode fazer selects no mesmo.(host, user e senha)
Não tem acesso a mais nada.
Não tem como o cliente ter acessos a conexões do sc se ele não tiver a senha (_lib/prod).
Não tem como o cliente ter acessos aos arquivos se ele não tem acesso ao ftp da VM.
No sistema existem 2 conexões a do banco de dados local e a do nosso banco no cloud computer (cliente não tem acesso).
Nosso login através da conexão ao nosso cloud (sc_lookup(rs,“select…”,"conexao)cloud), verifica a liberação do cliente. Para isso A VM deve ter acesso a internet.
Caso esteja sem acesso, o sc_lookup retorna com erro, registramos esse erro por até 3 dias, se não houve conexão nesses 3 dias, a partir do quarto dia o sistema é bloqueado.
É simples, funcional e seguro. Pelo menos tem sido para nós até o momento.
*VM= Virtual Machine.
Os clientes que usam esse formato, recebem uma imagem da máquina virtual e sobem a mesma em seus servidores que já são virtualizados.
Caroline,
Este teste você têm dentro do fonte, este fonte está no servidor do cliente?
O acesso ao BD de sua VM, está no sistema que está no servidor do cliente ?
O acesso ao BD de sua empresa, ocorre apenas no momento do login?, e este código PHP, onde está gravado, no HD do servidor de seu cliente, ou no HD do seu servidor?, pelo que entendi está no HD do servidor do seu cliente. O cliente tendo acesso a este código, não é só eliminar este código ou mudar o retorno para “burlar” a leitura a sua VM ?
Att,
Jocimar
Usuários remotos, neste contexto, não devem ter permissão root.
Uma forma de testar se um arquivo foi modificado é gerar um hash do arquivo que queira proteger e depois comparar quando necessário. Quando vc gera um hash de um arquivo, se mudar um espaço o hash resultante vai ser diferente.
Bom dia meus amigos.
Estou respondendo esse tópico no lugar da Caroline.
Li as respostas dela aqui e para mim elas estão bem claras.
Vou reforçar:
Quando o cliente exige que o sistema fique em sua rede interna, enviamos a imagem de uma máquina virtual VMWare com Linux instalado, com apache, php e o banco de dados postgres ou mysql + ambiente de produção do Scriptcase + os aplicativos do sistema.
No linux dessa máquina virtual, não tem ftp instalado nem o samba. O Cliente não tem acesso SSH, nem ftp, nem via rede local.
No banco de dados é criado um usuário para acesso ao banco com permissão apenas de leitura. Para o cliente executar seus backups.
O Cliente sobe essa imagem da máquina virtual em seu servidor (geralmente hoje os servidores já vem virtualizados).
Isso significa que:
Os fontes ficam no HD do cliente? Sim, mas dentro da Máquina virtual a qual o cliente não tem acesso.
O Cliente tem acesso aos dados do Banco de Dados? Sim, mas apenas consegue fazer selects, não consegue alterar tabelas, fazer inserções nem deleções por fora do sistema.
É Seguro? Nada é 100% seguro, mas nos 4 anos que usamos esse recurso nunca tivemos problema.
Em nosso contrato se o cliente ousar a invadir a máquina virtual e alterar o código fonte do Scriptcase, ele pode sofre penalidades jurídicas.
Se caso o cliente consiga alterar o código fonte para não mais acessar a validação e liberação do uso do sistema, saberemos pois em nossos logs quando o cliente fica mais de 3 dias úteis sem realizar o registro já alertamos a ele das cláusulas contratuais, bloqueamos qualquer atualização para esse cnpj e já entramos entramos em contato com nosso departamento jurídico (Isso nunca aconteceu).
Quando a performance de ter uma conexão externa(quando falo conexão é conexão scriptcase), é praticamente transparente.
Essa foi a solução que adotei em minha empresa e esta funcionando bem até hoje, apesar de ser uma solução que não gosto de adotar, por isso o cliente que exigir o sistema na sua rede local vai pagar bem mais caro por isso.
Pessoal,
Minhas considerações finais sobre o assunto…
Há muito deixei de me preocupar se o cliente tem acesso ou não aos fontes dos sistemas web… mas, a bem da verdade, é preciso que frise que existem clientes e CLIENTES e eu deixei de trabalhar com clientes, assim como deixei de fazer sistemas que não fossem muito específicos ou seja, o cliente que tiver acesso ao código fonte terá pouca oportunidade para negociá-lo.
Por ser uma aplicação web e estar consciente de todas os problemas de segurança que isso exige prefiro nem ficar com a guarda do sistema ou do DB, evitando assim responsabilidades futuras. Com isso, não preciso me preocupar com uma série de problemas advindos - além da segurança - velocidade, disponibilidade, etc… além do custo disso tudo que não incluo no preço do serviço.
Cada caso é um caso, mas na quase totalidade é assim - ficam excetuados apenas os casos de filantropia (aqueles que não cobro nada) aí os fontes ficam comigo o DB também e a hospedagem também.
Abraço a todos
Salam Aleikum.
Quando o cliente faz questão de manter o banco em seu domínio, eu fico com os fontes em meu servidor e o banco de dados fica onde o cliente quiser e, neste tipo de contrato existe uma cláusula de isenção de responsabilidade sobre a segurança do banco de dados e a velocidade de acesso. Assim como o Haroldo, neste tipo de contrato sempre cobro mais caro.
É um requisito deste tipo de contrato. Se o cliente não quiser assim, não será meu cliente. Sistemas, principalmente os que vão ficando parrudos, como o do Haroldo, acabam precisando de alguns requisitos para rodar.
Quem quer atender a todos, acaba não atendendo ninguém.
Exemplo de requisito é um sistema que tenho que não roda em IE. Se o cliente fizer questão de rodar no IE, procura outro que roda. Eu é que não vou ficar fazendo programação redundante só porque o IE não segue os padrões.
Em nosso caso o cliente quer o sistema e o banco na rede interna.