Re: [pgbr-geral] Como evitar autenticação trust?
Pessoal, Eu ia responder alguns posts, mas acho que é melhor encerrarmos o assunto. É muito polêmico. Há muitas opiniões diferentes em torno do mesmo assunto. Agradeço a todos que participaram, com certeza foi muito proveitoso a nossa discussão! Abraço! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
On 2011.M.4 0h44, Fabricio Srdic wrote: Não imaginei que causaria uma polêmica com essas proporções... Normal, há muita gente que não conhece arquitetura de sistemas e entretanto tem opiniões fortes. Sempre há discussões assim, por aqui e em outras listas. 1 - Proteger o patrimônio intelectual; 2 - Proteger o sistema contra a pirataria; Isso realmente não pode ser feito por sistemas, em última instância exigiria DRM. E DRM tem dois problemas graves: primeiro, prejudica o usuário; segundo, não funciona. O projeto de um banco de dados é algo muito valioso. O problema é que os dados são do cliente, e portanto ele tem direito à base de dados. E é inerentemente impossível separar os dados da estrutura. Antes dar as caras novamente por aqui na discussão resolvi dar uma olhada nos outros SGDB's comerciais, e eles foram o Oracle e o DB2, os dois senhores dos SGDB's. Na verdade, o PostgreSQL tem um /pedigree/ ainda melhor que o do DB2. Pelo menos o PosgreSQL, quando se chamava University Ingres, foi relacional, coisa que o DB2 nunca foi, mesmo quando se chamava RDS (era esse mesmo o nome?). O Oracle nem isso, é apenas uma cópia mal feita de apresentações feitas sobre uma versão de desenvolvimento do irmão menor do DB2, o SQL/DS. Vendo que mesmo os SGDB's comerciais são dessa maneira, acho que fui infeliz ao fazer a pergunta que iniciou essa discussão. Na verdade, não tem nada a ver. Os SGBDs comerciais não necessariamente fazem tudo certo. Na verdade, desde a conformidade aos padrões, arquitetura e boas práticas administrativas e de desenvolvimento, o parâmetro hoje é o PostgreSQL, nem sequer o DB2. O que temos de discutir é o que é pior, ruim, neutro, bom ou melhor, não o que algum concorrente, por mais rico ou popular que seja, faz. Talvez eu deveria ter sido mais claro nas minhas intenções. Talvez tivesse ajudado um pouco a encaminhar as discussões, mas o que importa é a substância, não a pessoa. Mas de qualquer forma creio que a minha preocupação com o projeto do banco é algo bastante válido. Tanto é que na Europa existe legislação específica para tratar de proteção de direitos dos autores de projetos de banco de dados. Se a legislação existe, é precisamente porque o segredo é impossível. E, acrescento, tentativas de segredo é contraproducente. attachment: leandro_gfc_dutra.vcf___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
2011/3/4 Fabricio Srdic fsa...@gmail.com: Como o meu propósito é criar um sistema com fins comerciais, e sendo um sistema comercializado em modo de concessão de licença de uso, surgiu uma preocupação de como proteger esse patrimônio intelectual. Como não estou vendendo o meu projeto, estou apenas concedendo a licença de uso deste, não é nada interessante ver esse patrimônio exposto dessa maneira. Fico com a sensação de vender um software e entregar os fontes para o usuário. Imagine, você comprar o windows e vir junto os fontes... Conheço casos na justiça em que softhouses processaram pessoas que contrataram os seus sistemas, cancelaram o serviço, então pegaram o banco de dados e contrataram um programador para desenvolver uma aplicação que acesse esse banco de dados. A informação armazenada é sempre de propriedade da empresa, no momento em que a empresa não quiser mais utilizar o seu sistema, você terá que entregar os dados. Qualquer empresa que entre no mercado com pensamento diferente deste, e tente utilizar isto para 'prender' clientes, esta fadada ao fracasso. Por isto ser de praxe, não há porque criar tais restrições sobre o conteúdo do banco. Um exemplo são os sistemas de almoxarifado e patrimônio, ao mudar de software, o conteúdo do banco é migrado para o novo schema. Então, antes de ter um bom software, tenha uma boa área comercial para convencer o cliente e utilizar o seu software. -- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works (myself) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Concordo com o Leandro, principalmente com relação a base de dados, os dados são do cliente pois foi horas pagas por ele para que os funcionários colocassem os dados lá. é como você alugar uma garagem, a garagem é sua, mas o carro não. Inclusive dependendo da empresa, mesmo você sendo dono do sistema, não pode simplesmente abrir a base e ler o que tem lá sem autorização do cliente, pois podem conter dados altamente sigilosos, o que deverá estar em contrato a concordancia dos envolvidos. Mas deixando de lado essa que com certeza é outra polemica; já que precisa realmente proteger seu sistema, concentre todas as funções e procedures no sistema e não na base de dados ou faça uma mesclagem, pois isso dará tanto trabalho para alguém entender sua lógica que compensará mais fazer outro sistema ao invez de copiar. Com relação as horas de trabalho dispensado na base de dados não tem jeito, faz parte de qualquer projeto e ja tem que fazer sabendo que será do cliente. Agora se concentrar tudo no sistema essa horas são suas. Claro que é muito melhor concentrar a maior parte do trabalho na base de dados por questões como integridade dos dados, facilitar desenvolvimento, deixar a aplicação mais rápida, o investimento se concentrará no servidor, etc, etc..., mas é cada caso um caso. Sinceramente acho que os desenvolvedores de SGDB's pensam que qualquer pessoa com minimo conhecimento na base pode criar tabelas e afins, mesmo que sem integridade relacional, por isso não faz sentido esconder isso. Só um comentário adicional, cuidado pra não tentar privar o cliente da base de dados, dependendo do caso, isso pode te dar um bom processo! (isso deve criar outra thread, rsrs) Marcelo Silva -Mensagem Original- From: Leandro Guimarães Faria Corcete DUTRA Sent: Friday, March 04, 2011 8:14 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Como evitar autenticação trust? On 2011.M.4 0h44, Fabricio Srdic wrote: Não imaginei que causaria uma polêmica com essas proporções... Normal, há muita gente que não conhece arquitetura de sistemas e entretanto tem opiniões fortes. Sempre há discussões assim, por aqui e em outras listas. 1 - Proteger o patrimônio intelectual; 2 - Proteger o sistema contra a pirataria; Isso realmente não pode ser feito por sistemas, em última instância exigiria DRM. E DRM tem dois problemas graves: primeiro, prejudica o usuário; segundo, não funciona. O projeto de um banco de dados é algo muito valioso. O problema é que os dados são do cliente, e portanto ele tem direito à base de dados. E é inerentemente impossível separar os dados da estrutura. Antes dar as caras novamente por aqui na discussão resolvi dar uma olhada nos outros SGDB's comerciais, e eles foram o Oracle e o DB2, os dois senhores dos SGDB's. Na verdade, o PostgreSQL tem um /pedigree/ ainda melhor que o do DB2. Pelo menos o PosgreSQL, quando se chamava University Ingres, foi relacional, coisa que o DB2 nunca foi, mesmo quando se chamava RDS (era esse mesmo o nome?). O Oracle nem isso, é apenas uma cópia mal feita de apresentações feitas sobre uma versão de desenvolvimento do irmão menor do DB2, o SQL/DS. Vendo que mesmo os SGDB's comerciais são dessa maneira, acho que fui infeliz ao fazer a pergunta que iniciou essa discussão. Na verdade, não tem nada a ver. Os SGBDs comerciais não necessariamente fazem tudo certo. Na verdade, desde a conformidade aos padrões, arquitetura e boas práticas administrativas e de desenvolvimento, o parâmetro hoje é o PostgreSQL, nem sequer o DB2. O que temos de discutir é o que é pior, ruim, neutro, bom ou melhor, não o que algum concorrente, por mais rico ou popular que seja, faz. Talvez eu deveria ter sido mais claro nas minhas intenções. Talvez tivesse ajudado um pouco a encaminhar as discussões, mas o que importa é a substância, não a pessoa. Mas de qualquer forma creio que a minha preocupação com o projeto do banco é algo bastante válido. Tanto é que na Europa existe legislação específica para tratar de proteção de direitos dos autores de projetos de banco de dados. Se a legislação existe, é precisamente porque o segredo é impossível. E, acrescento, tentativas de segredo é contraproducente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Pessoal, Vejam bem, os dados são sim do cliente, mas a estrutura não. Ou seja, por exemplo, views, stored procedures, external functions, tudo isso não pertence ao cliente. Porque isso faz parte estrutura do banco de dados. O modo como as tabelas estão organizadas no banco faz parte da estrutura. Isso é patrimônio intelectual. Andei lendo alguma legislação a respeito. Para vocês terem uma idéia, quando um cliente cancela o seu sistema você é obrigado a disponibilizar os dados para o cliente de forma que qualquer plataforma de programação possa acessá-los. Você não pode restringir os acesso aos dados por parte do cliente, por menor que seja essa restrição. Se, ao cancelar o sistema, você deixa no cliente a sua base de dados em Postgres mesmo, você está na verdade limitando o acesso do seu cliente aos dados, pois, não são todas as pltaformas de programação que conseguem trabalhar com dll's e não são todas que possui tipos de dados compatíveis com as utilizadas em dll's. Se analisarmos bem, a maneira correta de disponibilizar os dados para o cliente em um eventual cancelamento seria disponibilizar esses dados em arquivos txt em formato CVS, e os nomes dos campos e tabelas devem estar totalmente claros. Dessa maneira, qualquer que seja a plataforma escolhida o cliente vai poder acessar os dados, e qualquer um que queira fazer uma importação desses dados para uma eventual integração irá conseguir. Resumindo: O cliente deve ser capaz de acessar os seus dados como e quando quiser. Isso é apenas um exemplo, mas que ilustra um pouco melhor a questão. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Dá uma olhada nisso, não resolve todo o problema mas uma parte dele pelo menos. http://www.enterprisedb.com/products-services-training/products/complementary-enterprisedb-products/pl/secure Abraço, Fabiano Machado Dias Em 4/3/2011 00:44, Fabricio Srdic escreveu: Boa noite a todos Gostaria de agradeçer a todos que opinaram. Não imaginei que causaria uma polêmica com essas proporções... Pessoal, quando lançei a pergunta sobre a questão do trust na verdade tinha duas preocupações: 1 - Proteger o patrimônio intelectual; 2 - Proteger o sistema contra a pirataria; A 2ª opção é possível contornar com sucesso. Mas a primeira parece que não é possível. O projeto de um banco de dados é algo muito valioso. O banco de dados é a parte mais importante de qualquer que seja o sistema. O modo como o banco é projetado, a lógica utilizada, os métodos utilizados para resolver os problemas de análise, tudo isso envolve muito investimento e pesquisa. Alguns podem achar loucura o que vou dizer, mas considero um projeto de banco de dados mais valioso do que qualquer código-fonte de qualquer aplicação que acesse esse mesmo banco de dados. Como o meu propósito é criar um sistema com fins comerciais, e sendo um sistema comercializado em modo de concessão de licença de uso, surgiu uma preocupação de como proteger esse patrimônio intelectual. Como não estou vendendo o meu projeto, estou apenas concedendo a licença de uso deste, não é nada interessante ver esse patrimônio exposto dessa maneira. Fico com a sensação de vender um software e entregar os fontes para o usuário. Imagine, você comprar o windows e vir junto os fontes... Conheço casos na justiça em que softhouses processaram pessoas que contrataram os seus sistemas, cancelaram o serviço, então pegaram o banco de dados e contrataram um programador para desenvolver uma aplicação que acesse esse banco de dados. Antes dar as caras novamente por aqui na discussão resolvi dar uma olhada nos outros SGDB's comerciais, e eles foram o Oracle e o DB2, os dois senhores dos SGDB's. Pude verificar que os dois tambem não oferecem autenticação a nível de banco, ou seja, novamente não é o DBA que dá a ultima palavra sobre quem pode ou não acessar o banco, é o administrador do servidor. Vendo que mesmo os SGDB's comerciais são dessa maneira, acho que fui infeliz ao fazer a pergunta que iniciou essa discussão. Talvez eu deveria ter sido mais claro nas minhas intenções. Peço desculpas. O problema não é o Postgres ou o Firebird. A filosofia dos SGDB's em geral é assim. Com relação aos SGDB's não há nada o que fazer. Mas de qualquer forma creio que a minha preocupação com o projeto do banco é algo bastante válido. Tanto é que na Europa existe legislação específica para tratar de proteção de direitos dos autores de projetos de banco de dados. Novamente agradeço a todos que participaram! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ; ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
2011/3/4 Fabricio Srdic fsa...@gmail.com: Vejam bem, os dados são sim do cliente, mas a estrutura não. Conceito básico de teoria de dados. Não há dados sem estrutura. Ou seja, por exemplo, views Visões (relações derivadas) fazem parte da estrutura básica. stored procedures, external functions, tudo isso não pertence ao cliente. Porque isso faz parte estrutura do banco de dados. Absolutamente não. Isso é código executável, e faz parte da aplicação, não da base de dados, e muito menos de sua estrutura. Somente está na base porque não faz sentido colocar a rede (com latência c) entre a lógica e os dados. Existe um caso interessante, que é o código que suporta as restrições de integridade. Este, por mais que seja expresso na mesma linguagem que a lógica da aplicação, na verdade faz parte da estrutura, e portanto pertence ao cliente. Ou deveria. O modo como as tabelas estão organizadas no banco faz parte da estrutura. Isso é patrimônio intelectual. Pode até ser, de acordo com a lei atual. Mas não quer dizer que a lei seja justa ou razoável, como qualquer brasileiro com um mínimo de conhecimento ou experiência de vida deveria saber. Aliás, é impossível separar o que é do cliente (dados) do que pode, talvez, não ser (estrutura). Portanto, mesmo que um tribunal fosse tentar estabelecer essa distinção, qualquer advogado de meia tigela mostraria que é absurdo. Se, ao cancelar o sistema, você deixa no cliente a sua base de dados em Postgres mesmo, você está na verdade limitando o acesso do seu cliente aos dados, pois, não são todas as pltaformas de programação que conseguem trabalhar com dll's E o que DLLs, quem nem são inerentes ao PostgreSQL, têm a ver com o caso? DLL é uma excrecência da plataforma IBM OS/2 copiada pelo MS Windows, exclusiva a essas plataformas. Nos sistemas operacionais ‘de verdade’ (POSIX, inclusive Unix e GNU/Linux), usamos SOs. Também não entendo o que plataforma de programação tem a ver com o caso. Num caso de encerramento de contrato de suporte, o que o usuário quer é maneira de exportar os dados para outra plataforma, ou a possibilidade de continuar a usar a mesma. O PostgreSQL é livre, e tem todas as ferramentas de extração e interface possíveis e imagináveis. Mesmo que o usuário tenha alguma plataforma estranha, nenhum SGBD tem interface para tantas linguagens de programação e plataformas operacionais quanto o PostgreSQL. e não são todas que possui tipos de dados compatíveis com as utilizadas em dll's DLLs determinam uma única plataforma de programação: interfaces C em MS Windows, a menos que ainda sejas usuário de IBM OS/2. O que não faz muita diferença, porque o MS Windows nada mais é que uma versão lobotomizada nalguns aspectos, extendida noutros, do IBM OS/2. Aliás, seu primeiro nome foi MS OS/2 3.0 NT i80860. Pelo contrário, tipos de dados não têm nada a ver com DLLs, a menos que, além de usar as interfaces C, se programe também em C, e aí são os tipos de dados do C. Nada a ver com PostgreSQL. Se analisarmos bem, a maneira correta de disponibilizar os dados para o cliente em um eventual cancelamento seria disponibilizar esses dados em arquivos txt em formato CVS Não existe um formato CVS, e txt não é formato de dados. Formatos de dados são TSV (preferido), SSV (razoável) e CSV (horrível), e nenhum deles expressa o mínimo de uma base, nem sequer as chaves. O cliente que aceitar isso vai dançar, merecidamente. O mínimo absoluto seria a base de dados PostgreSQL, opcionalmente com código‐fonte obscurecido — mas o código‐fonte das restrições de integridade não pode ser obscurecido. Desculpai o tamanho da mensagem, mas havia muita coisa a esclarecer. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Acho no mínimo curiosa a visão de algumas pessoas sobre programação e propriedade intelectual. Vejo que dão valor demais ao produto, quando o que importa mesmo é o serviço prestado com este produto ao cliente. Claro que o bom é ter os dois, mas o diferencial vem do segundo. Utilizemos como exemplo o Sistema QUALQUER de Gestão Comercial... Sou o programador principal deste sistema e desenvolvi um algoritmo que faz o cálculo dos impostos de uma forma otimizada, fazendo com que o tempo de determinada rotina baixe, de 10 minutos para 10 segundos. Otimizei a rotina, pois estava mal escrita. Fico muito orgulhoso e isso prá mim tem muito valor, porém para o sistema inteiro ou para o cliente isso pode não ter a mesma importância que tem prá mim. Posso não querer compartilhar isso com ninguém, pois me deu trabalho fazer e não quero dar isso de mão beijada. Mas com 30 minutos de envolvimento outro programador foi lá, fez de outra maneira (seguindo a mesma lógica ou não) e obteve o mesmo resultado. Outra possibilidade é deixar que qualquer pessoa pegue o que tenho, melhore e me devolva agora rodando em 5 segundos. Também tem outro cenário... a preocupação de que alguém venha a hackear meu sistema inteiro e, ao invés de fazer um do zero, se aproveite do que já fiz. - Em primeiro lugar ele terá bastante trabalho para entender a forma como pensei o sistema; - Depois ele vai achar que determinada rotina faria diferente; - Ele terá bastante trabalho para colocar este sistema para funcionar; - Quando não funcionar ele não poderá apelar para mim, desta forma não vai ter segurança para levá-lo adiante; - Ele não vai me ligar pedindo ajuda; - Vai literalmente morrer na casca. Outra possibilidade é deixar que qualquer pessoa possa pegar os fontes do meu sistema e melhorá-lo. Ou ainda o implemente em clientes e me contate se precisar de uma apoio ou melhoria, alavancando de uma forma ou de outra meus negócios e de quebra, melhorando meu produto. Tenho visto hoje em dia um grande movimento neste sentido. Tudo está indo para o código aberto, inclusive os ERPs. (vide OpenERP, OpenTaps, OfBiz, OpenBravo+-,Stoq) Se eu não abrir o meus sistema QUALQUER vão usar outro. E como tem outros de código aberto (muito completos principalmente por utilizarem este modelo de negócio). Por quê vão querer ter o trabalho de hackear meu engessado e ultrapassado sistema? Isso é só para contextualizar... Não estou dizendo que seu sistema seja assim. O que quero demonstrar é que, a menos que meu sistema seja muito específico para um nicho de mercado ou ramo de negócio, que nenhum outro hoje atenda, não vejo vantagens em trabalhar no modelo de código fechado. Isso só vai atrasar me negócio. Este modelo ficou para trás. Mesmo a Microsoft... Se buscasse desesperadamente uma forma de impedir a pirataria do seu sistema, não estaria onde está hoje. Claro que esta é tão somente minha visão pessoal, não levem a mal. Abraço Amigos! Att. Alex Em 04-03-2011 13:32, Leandro DUTRA escreveu: 2011/3/4 Fabricio Srdicfsa...@gmail.com: Vejam bem, os dados são sim do cliente, mas a estrutura não. Conceito básico de teoria de dados. Não há dados sem estrutura. Ou seja, por exemplo, views Visões (relações derivadas) fazem parte da estrutura básica. stored procedures, external functions, tudo isso não pertence ao cliente. Porque isso faz parte estrutura do banco de dados. Absolutamente não. Isso é código executável, e faz parte da aplicação, não da base de dados, e muito menos de sua estrutura. Somente está na base porque não faz sentido colocar a rede (com latênciac) entre a lógica e os dados. Existe um caso interessante, que é o código que suporta as restrições de integridade. Este, por mais que seja expresso na mesma linguagem que a lógica da aplicação, na verdade faz parte da estrutura, e portanto pertence ao cliente. Ou deveria. O modo como as tabelas estão organizadas no banco faz parte da estrutura. Isso é patrimônio intelectual. Pode até ser, de acordo com a lei atual. Mas não quer dizer que a lei seja justa ou razoável, como qualquer brasileiro com um mínimo de conhecimento ou experiência de vida deveria saber. Aliás, é impossível separar o que é do cliente (dados) do que pode, talvez, não ser (estrutura). Portanto, mesmo que um tribunal fosse tentar estabelecer essa distinção, qualquer advogado de meia tigela mostraria que é absurdo. Se, ao cancelar o sistema, você deixa no cliente a sua base de dados em Postgres mesmo, você está na verdade limitando o acesso do seu cliente aos dados, pois, não são todas as pltaformas de programação que conseguem trabalhar com dll's E o que DLLs, quem nem são inerentes ao PostgreSQL, têm a ver com o caso? DLL é uma excrecência da plataforma IBM OS/2 copiada pelo MS Windows, exclusiva a essas plataformas. Nos sistemas operacionais ‘de verdade’ (POSIX, inclusive Unix e GNU/Linux), usamos SOs. Também não entendo o
Re: [pgbr-geral] Como evitar autenticação trust?
Assino embaixo do que o Alexsandro escreveu. E vamos todos ler de novo a Catedral e o Bazar, gente: http://pt.wikisource.org/wiki/A_Catedral_e_o_Bazar http://pt.wikisource.org/wiki/A_Catedral_e_o_Bazar[]s Em 4 de março de 2011 15:18, Alexsandro Haag alexsandro.h...@gmail.comescreveu: Acho no mínimo curiosa a visão de algumas pessoas sobre programação e propriedade intelectual. Vejo que dão valor demais ao produto, quando o que importa mesmo é o serviço prestado com este produto ao cliente. Claro que o bom é ter os dois, mas o diferencial vem do segundo. Utilizemos como exemplo o Sistema QUALQUER de Gestão Comercial... Sou o programador principal deste sistema e desenvolvi um algoritmo que faz o cálculo dos impostos de uma forma otimizada, fazendo com que o tempo de determinada rotina baixe, de 10 minutos para 10 segundos. Otimizei a rotina, pois estava mal escrita. Fico muito orgulhoso e isso prá mim tem muito valor, porém para o sistema inteiro ou para o cliente isso pode não ter a mesma importância que tem prá mim. Posso não querer compartilhar isso com ninguém, pois me deu trabalho fazer e não quero dar isso de mão beijada. Mas com 30 minutos de envolvimento outro programador foi lá, fez de outra maneira (seguindo a mesma lógica ou não) e obteve o mesmo resultado. Outra possibilidade é deixar que qualquer pessoa pegue o que tenho, melhore e me devolva agora rodando em 5 segundos. Também tem outro cenário... a preocupação de que alguém venha a hackear meu sistema inteiro e, ao invés de fazer um do zero, se aproveite do que já fiz. - Em primeiro lugar ele terá bastante trabalho para entender a forma como pensei o sistema; - Depois ele vai achar que determinada rotina faria diferente; - Ele terá bastante trabalho para colocar este sistema para funcionar; - Quando não funcionar ele não poderá apelar para mim, desta forma não vai ter segurança para levá-lo adiante; - Ele não vai me ligar pedindo ajuda; - Vai literalmente morrer na casca. Outra possibilidade é deixar que qualquer pessoa possa pegar os fontes do meu sistema e melhorá-lo. Ou ainda o implemente em clientes e me contate se precisar de uma apoio ou melhoria, alavancando de uma forma ou de outra meus negócios e de quebra, melhorando meu produto. Tenho visto hoje em dia um grande movimento neste sentido. Tudo está indo para o código aberto, inclusive os ERPs. (vide OpenERP, OpenTaps, OfBiz, OpenBravo+-,Stoq) Se eu não abrir o meus sistema QUALQUER vão usar outro. E como tem outros de código aberto (muito completos principalmente por utilizarem este modelo de negócio). Por quê vão querer ter o trabalho de hackear meu engessado e ultrapassado sistema? Isso é só para contextualizar... Não estou dizendo que seu sistema seja assim. O que quero demonstrar é que, a menos que meu sistema seja muito específico para um nicho de mercado ou ramo de negócio, que nenhum outro hoje atenda, não vejo vantagens em trabalhar no modelo de código fechado. Isso só vai atrasar me negócio. Este modelo ficou para trás. Mesmo a Microsoft... Se buscasse desesperadamente uma forma de impedir a pirataria do seu sistema, não estaria onde está hoje. Claro que esta é tão somente minha visão pessoal, não levem a mal. Abraço Amigos! Att. Alex Em 04-03-2011 13:32, Leandro DUTRA escreveu: 2011/3/4 Fabricio Srdicfsa...@gmail.com: Vejam bem, os dados são sim do cliente, mas a estrutura não. Conceito básico de teoria de dados. Não há dados sem estrutura. Ou seja, por exemplo, views Visões (relações derivadas) fazem parte da estrutura básica. stored procedures, external functions, tudo isso não pertence ao cliente. Porque isso faz parte estrutura do banco de dados. Absolutamente não. Isso é código executável, e faz parte da aplicação, não da base de dados, e muito menos de sua estrutura. Somente está na base porque não faz sentido colocar a rede (com latênciac) entre a lógica e os dados. Existe um caso interessante, que é o código que suporta as restrições de integridade. Este, por mais que seja expresso na mesma linguagem que a lógica da aplicação, na verdade faz parte da estrutura, e portanto pertence ao cliente. Ou deveria. O modo como as tabelas estão organizadas no banco faz parte da estrutura. Isso é patrimônio intelectual. Pode até ser, de acordo com a lei atual. Mas não quer dizer que a lei seja justa ou razoável, como qualquer brasileiro com um mínimo de conhecimento ou experiência de vida deveria saber. Aliás, é impossível separar o que é do cliente (dados) do que pode, talvez, não ser (estrutura). Portanto, mesmo que um tribunal fosse tentar estabelecer essa distinção, qualquer advogado de meia tigela mostraria que é absurdo. Se, ao cancelar o sistema, você deixa no cliente a sua base de dados em Postgres mesmo, você está na verdade limitando o acesso do seu cliente aos dados, pois, não são todas as
Re: [pgbr-geral] Como evitar autenticação trust?
Gente, podemos dar o assunto como encerrado? :) Thiago Bocchile On 2011 3 4 16:10, Fábio Telles Rodriguez fabio.tel...@gmail.com wrote: Assino embaixo do que o Alexsandro escreveu. E vamos todos ler de novo a Catedral e o Bazar, gente: http://pt.wikisource.org/wiki/A_Catedral_e_o_Bazar http://pt.wikisource.org/wiki/A_Catedral_e_o_Bazar[]s Em 4 de março de 2011 15:18, Alexsandro Haag alexsandro.h...@gmail.comescreveu: Acho no mínimo curiosa a visão de algumas pessoas sobre programação e propriedade intelectual... -- Atenciosamente, Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: ... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Buenas! Só pra complementar, o acesso Trust é extremamente necessário para evitar que um banco de dados se perca, por exemplo, quando um 'DBA' tenta agir de má fé. Vou usar um cenário mirabolante como exemplo: - Um 'DBA', descontente com o salário que ganha, decide usar um 'artifício' para aumentar sua credibilidade e remuneração. Faz um dump na tabela de usuários, guarda o dump com ele e cria uma função que detona os dados de usuários (menos o seu acesso) disparada por uma rotina no SO. - Daí pede pra sair dizendo que recebeu uma proposta melhor. Independente do que o dono ofereça como contra-proposta para mantê-lo, sai da empresa, pois sabe que a armadilha está montada, sem deixar a senha administrativa de acesso. Em princípio, ninguém percebe nada, pois os acessos ao banco e seus dados continuam normalmente. De repente, boom! Fim do acesso ao banco. - A empresa tenta ligar pro ex-'DBA' que nega o auxílio e afirma que qualquer outro DBA poderá resolver o caso em poucas horas. Tentam chamar outro DBA, mas este sem acesso administrativo ao banco, nada pode fazer. Mesmo que liguem pro 'DBA', ele pode fornecer qualquer senha como sendo a de admin que não irá funcionar, camuflando assim sua falcatrua. - Novamente a empresa liga (já em desespero) pro 'DBA' e este vai, resolve o problema em algumas horas (diria minutos, afinal, ele sabe exatamente o que fazer), deixa todo mundo na empresa feliz e contente, porém deixa uma nova bomba similar por garantia, ficando assim com status de FODÃO, pois qualquer outro DBA chamado não teria como resolver o problema. - Ao se encontrar com o dono, que vem agradecer, diz que gostaria de ter permanecido na empresa, mas que o salário estava muito aquem de seu conhecimento. Se o dono não cair, a nova bomba já está armada pra uma nova tentativa. Do contrário, pede o que quiser (acima da contra-proposta citada anteriormente) e certamente será contemplado, afinal, dados são o coração do negócio. Com o acesso Trust, qualquer DBA legítimo pode interromper essa falcatrua ao afirmar que a tabela de usuários foi deletada propositalmente, restauraria a mesma e eliminaria qualquer rotina mal intencionada que estivesse no SO. Eu sei que isso é um caso fictício (e seria uma abominação) mas sem o acesso Trust seria um cenário completamente possível. Abraços, Daniel Caña Em 2 de março de 2011 19:05, Tiago Adami adam...@gmail.com escreveu: Em 2 de março de 2011 17:36, Osvaldo Kussama osvaldo.kuss...@gmail.com escreveu: Repare que o usuário com poderes de super-usuário pode modificar o local do arquivo pg_hba.conf [1], dar um restart do PostgreSQL e dessa forma liberar qualquer tipo de acesso. Creio que a grande falha de segurança é a existência, indevida, de usuários com poderes que não deveriam ter. Se você deu a chave de sua casa a um ladrão então não pode reclamar de ter sido roubado. Osvaldo [1] http://www.postgresql.org/docs/current/interactive/runtime-config-file-locations.html A segurança do banco de dados se baseia em 2 práticas impreteríveis: 1) não dar acesso de root a quem não merece; 2) restringir o acesso ao servidor físico (isso mesmo ao hardware) somente aos administradores. Certa vez eu não tinha acesso aos arquivos de configuração do servidor em um cliente. Mas tinha acesso ao servidor físico. Mudei alguns parâmetros no GRUB [1], e... Voilá! Consegui alterar a senha do root. Só para que fique registrado: outros SGBDs utilizam os protocolos de segurança (por assim se dizer) do sistema operacional, como o IBM DB2. Tendo a senha do root ou administrator, você toma conta de tudo. [1] http://www.debuntu.org/recover-root-password-single-user-mode-and-grub -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Em Qua 02 Mar 2011, às 16:57:12, Thiago Bocchile escreveu: Então galera, mas o que ele precisa é de uma forma de não alterarem o pg_hba pelo que eu entendi, certo? A idéia que eu dei anteriormente, usando um dispositivo READ ONLY para colocar o pg_hba é valida, por mais que pareça uma gambiarra. Essa idéia funciona tanto no Linux quanto no Windows, é só apontar para o arquivo pg_hba.conf da unidade externa (pode ser CD/DVD/Hd externo com read only ou meu favorito: unidade de rede, para windows). Mesmo o cara sendo R00T M4573R, ele não vai conseguir alterar NADA no arquivo, pois teoricamente, não da para gravar, correto?! Bom, tenta ai a sugestão, mas como alguns colegas falaram: se tem gente com acesso root, então não temos uma regra clara de segurança ai. ;) * Thiago Bocchile* *tyk...@gmail.com* Linux User # 527010 http://about.me/tykoth +551381318881 Não pode alterar na mídia em questão, mas se você der um type/cat no arquivo, poderá direcionar a saída para outro dispositivo, então gravar uma nova mídia e substituí-la. Como já foi comentado, acesso físico ao servidor, e/ou, acesso com privilégios ao servidor é dar permissão para fazer o que for necessário para se ter acesso mal intencionado ao que quiser. Nos cursos de firewall para linux isto é a primeira coisa que é comentado na questão de segurança, ou não se fala em segurança, aí já é outra coisa! Atenciosamente, Jocimar de Oliveira www.erp-gerencia.com Paraná - Região dos Campos Gerais Atuando como: Desenvolvedor de Sistemas - Profissional liberal Início das atividades: 19/mar/1989 - 21 anos Linguagem de programação: FlagShip S.O.: Linux Migrando para linguagem de programação: Java (Desktop) SGBD: PostGreSQL IDE: NetBeans 6.9.1 S.O.: Linux ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Daniel !!! Isso dá um filme heim, rsrsrs Marcelo Silva -- From: Daniel Caña Sent: Thursday, March 03, 2011 9:02 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Buenas! Só pra complementar, o acesso Trust é extremamente necessário para evitar que um banco de dados se perca, por exemplo, quando um 'DBA' tenta agir de má fé. Vou usar um cenário mirabolante como exemplo: - Um 'DBA', descontente com o salário que ganha, decide usar um 'artifício' para aumentar sua credibilidade e remuneração. Faz um dump na tabela de usuários, guarda o dump com ele e cria uma função que detona os dados de usuários (menos o seu acesso) disparada por uma rotina no SO. - Daí pede pra sair dizendo que recebeu uma proposta melhor. Independente do que o dono ofereça como contra-proposta para mantê-lo, sai da empresa, pois sabe que a armadilha está montada, sem deixar a senha administrativa de acesso. Em princípio, ninguém percebe nada, pois os acessos ao banco e seus dados continuam normalmente. De repente, boom! Fim do acesso ao banco. - A empresa tenta ligar pro ex-'DBA' que nega o auxílio e afirma que qualquer outro DBA poderá resolver o caso em poucas horas. Tentam chamar outro DBA, mas este sem acesso administrativo ao banco, nada pode fazer. Mesmo que liguem pro 'DBA', ele pode fornecer qualquer senha como sendo a de admin que não irá funcionar, camuflando assim sua falcatrua. - Novamente a empresa liga (já em desespero) pro 'DBA' e este vai, resolve o problema em algumas horas (diria minutos, afinal, ele sabe exatamente o que fazer), deixa todo mundo na empresa feliz e contente, porém deixa uma nova bomba similar por garantia, ficando assim com status de FODÃO, pois qualquer outro DBA chamado não teria como resolver o problema. - Ao se encontrar com o dono, que vem agradecer, diz que gostaria de ter permanecido na empresa, mas que o salário estava muito aquem de seu conhecimento. Se o dono não cair, a nova bomba já está armada pra uma nova tentativa. Do contrário, pede o que quiser (acima da contra-proposta citada anteriormente) e certamente será contemplado, afinal, dados são o coração do negócio. Com o acesso Trust, qualquer DBA legítimo pode interromper essa falcatrua ao afirmar que a tabela de usuários foi deletada propositalmente, restauraria a mesma e eliminaria qualquer rotina mal intencionada que estivesse no SO. Eu sei que isso é um caso fictício (e seria uma abominação) mas sem o acesso Trust seria um cenário completamente possível. Abraços, Daniel Caña Em 2 de março de 2011 19:05, Tiago Adami adam...@gmail.com escreveu: Em 2 de março de 2011 17:36, Osvaldo Kussama osvaldo.kuss...@gmail.com escreveu: Repare que o usuário com poderes de super-usuário pode modificar o local do arquivo pg_hba.conf [1], dar um restart do PostgreSQL e dessa forma liberar qualquer tipo de acesso. Creio que a grande falha de segurança é a existência, indevida, de usuários com poderes que não deveriam ter. Se você deu a chave de sua casa a um ladrão então não pode reclamar de ter sido roubado. Osvaldo [1] http://www.postgresql.org/docs/current/interactive/runtime-config-file-locations.html A segurança do banco de dados se baseia em 2 práticas impreteríveis: 1) não dar acesso de root a quem não merece; 2) restringir o acesso ao servidor físico (isso mesmo ao hardware) somente aos administradores. Certa vez eu não tinha acesso aos arquivos de configuração do servidor em um cliente. Mas tinha acesso ao servidor físico. Mudei alguns parâmetros no GRUB [1], e... Voilá! Consegui alterar a senha do root. Só para que fique registrado: outros SGBDs utilizam os protocolos de segurança (por assim se dizer) do sistema operacional, como o IBM DB2. Tendo a senha do root ou administrator, você toma conta de tudo. [1] http://www.debuntu.org/recover-root-password-single-user-mode-and-grub -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
huahuahua... Mas eu avisei que seria um cenário mirabolante... ;oP Em 3 de março de 2011 09:29, Marcelo Silva (IG) marc...@ig.com.brescreveu: Daniel !!! Isso dá um filme heim, rsrsrs Marcelo Silva ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Quando um novato faz uma pergunta, eu entendo. Eu também já fui novato e acho que faz parte do aprendizado. Mas ouvir um monte de gente criando polêmica besta, sugerindo até que o PostgreSQL tem um bug, já é demais!!! Claro que o PostgreSQL tem defeitos, e não são poucos. Mas o pessoal tem de tomar mais cuidado com o que fala aqui na lista. No último PGCon Brasil, houve uma palestra que alertou para o fato da lista aqui ser pública, qualquer pessoa lê. Basta fazer uma busca no Google, que você verá esta lista aparacendo várias vezes. Então, se você não quer se queimar profissionalmente, tome mais cuidado com o que escreve. Não saia chutando. Não é uma bronca, é um toque, pode lhe custar uma vaga para um emprego, por exemplo. -- Atenciosamente, Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
off Acredite, ja vi casos semelhantes, e que deram certo! /off Thiago Bocchile On 2011 3 3 09:02, Daniel Caña dbcana.uni...@gmail.com wrote: Buenas! Só pra complementar, o acesso Trust é extremamente necessário para evitar que um banco de dados se perca, por exemplo, quando um 'DBA' tenta agir de má fé. Vou usar um cenário mirabolante como exemplo: - Um 'DBA', descontente com o salário que ganha, decide usar um 'artifício' para aumentar sua credibilidade e remuneração. Faz um dump na tabela de usuários, guarda o dump com ele e cria uma função que detona os dados de usuários (menos o seu acesso) disparada por uma rotina no SO. - Daí pede pra sair dizendo que recebeu uma proposta melhor. Independente do que o dono ofereça como contra-proposta para mantê-lo, sai da empresa, pois sabe que a armadilha está montada, sem deixar a senha administrativa de acesso. Em princípio, ninguém percebe nada, pois os acessos ao banco e seus dados continuam normalmente. De repente, boom! Fim do acesso ao banco. - A empresa tenta ligar pro ex-'DBA' que nega o auxílio e afirma que qualquer outro DBA poderá resolver o caso em poucas horas. Tentam chamar outro DBA, mas este sem acesso administrativo ao banco, nada pode fazer. Mesmo que liguem pro 'DBA', ele pode fornecer qualquer senha como sendo a de admin que não irá funcionar, camuflando assim sua falcatrua. - Novamente a empresa liga (já em desespero) pro 'DBA' e este vai, resolve o problema em algumas horas (diria minutos, afinal, ele sabe exatamente o que fazer), deixa todo mundo na empresa feliz e contente, porém deixa uma nova bomba similar por garantia, ficando assim com status de FODÃO, pois qualquer outro DBA chamado não teria como resolver o problema. - Ao se encontrar com o dono, que vem agradecer, diz que gostaria de ter permanecido na empresa, mas que o salário estava muito aquem de seu conhecimento. Se o dono não cair, a nova bomba já está armada pra uma nova tentativa. Do contrário, pede o que quiser (acima da contra-proposta citada anteriormente) e certamente será contemplado, afinal, dados são o coração do negócio. Com o acesso Trust, qualquer DBA legítimo pode interromper essa falcatrua ao afirmar que a tabela de usuários foi deletada propositalmente, restauraria a mesma e eliminaria qualquer rotina mal intencionada que estivesse no SO. Eu sei que isso é um caso fictício (e seria uma abominação) mas sem o acesso Trust seria um cenário completamente possível. Abraços, Daniel Caña Em 2 de março de 2011 19:05, Tiago Adami adam...@gmail.com escreveu: Em 2 de março de 2011 17:36, Osvaldo Kussama osvaldo.kuss...@gmail.com escreveu: Re... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Mas... possível Este seu foi um exemplo, vou mostrar um REAL que aconteceu comigo e a pouco tempo (3 anos atrás): A minha empresa foi contratada para substituir um programador de uma clinica pequena (ou seja, mexe com pessoas, vidas! O que deixa a questão ética deste “profissional” mais na vista). Os diretores pediram para que eu fosse lá 1 vez por semana, em horários que ele não estava, para fazer ‘backup’ dos dados e sistema. Em 1 mês, eles iriam dispensa-lo (lógico, ele não sabia). Era um sistema em Visual FoxPro e DBF. No momento achava q eles estavam fazendo uma “cachorrada” com o programador. No dia da dispensa, eu fui antes, travei todos os acessos remotos que ele tinha (praticamente o servidor não tinha internet! rs), fiz um backup e fui embora. Segunda começo normalmente no lugar. Na sexta, uma das telefonistas entra na sala da diretoria, falando que não aguenta mais a pressão! Pois o programador anterior ficava “infernizando” ela (ligando até na casa dela) para que ela instalasse um programa no servidor, pois ele estava “negociando” a volta dele para a empresa. Ela mostrou até uma gravação dele (que em ultimo caso, seria usada como prova legal), realmente forçando a barra. Conversando com os diretores, soube que isto que ele tentou fazer, já tinha feito em outra empresa (eles souberam conversando com o ex-chefe anterior dele), quando foi mandado embora. Por isto da cautela e de não colocar ele de “aviso” ou falar do que eu fazia lá. Então, este cenário é totalmente possível e a existência do “acesso trust” necessária. Mas, acho que entendi o que o Fa quer. Imaginem um desenvolvedor criar um produto, porém, algum engraçadinho “pirateia” este produto ou tenta roubar os dados da base de dados. Este cenário é totalmente “travavel” via programação, restrição de acessos (root ou administrador) ou qualquer outra forma. Agora, se o cliente deste produto, não está nem ai para isto. Digo isto, pois, existem empresas (micro e pequenas) de pessoas que começaram com “uma portinha” e virou algo maior, que nem sabem o que é root, administrador. Acham que é besteira colocar senha no computador. Querem que o computador ligue e pronto, mostre tudo. E deixar um computador parado no canto, só porque é o servidor! Nem pensar. Computador é muito caro para ficar parado “sem fazer nada”. Trabalho com várias destas e sei o que estou falando. (AGORA DÁ UM FILME DE COMÉDIA) Em uma delas me pediram para desfazer toda a “porcaria” que eu tinha feito no computador principal deles (Windows XP). O que era a porcaria? Criei a senha de adm e de usuário normal. Os funcionários quando iam usar ele, entravam na senha de usuário. Até que um dos filhos do patrão, quis colocar um joguinho neste computador! Não conseguiu! Legal, mas o papai não gostou. Nestes tipos de empresas, acredito que QUALQUER banco de dados sério, não vai conseguir esta segurança. Alias, é uma pena, pois antes, estas empresas não tinham $$$ para um banco sério, agora que tem o Postgres, não tem “filosofia” par isto. Talvez ter a opção na instalação, mas ai, caímos de novo no problema de “esquecimento” de senha ou “profissionais” mal intencionados. Eduardo Az Dep.TI EMBRASIS +55(11)2122-0241 PABX +55(11)8125-3845 TIM eduard...@embrasis.com.br From: Daniel Caña Sent: Thursday, March 03, 2011 10:36 AM To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? huahuahua... Mas eu avisei que seria um cenário mirabolante... ;oP Em 3 de março de 2011 09:29, Marcelo Silva (IG) marc...@ig.com.br escreveu: Daniel !!! Isso dá um filme heim, rsrsrs Marcelo Silva ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral wlEmoticon-confusedsmile[1].png___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Boa noite a todos Gostaria de agradeçer a todos que opinaram. Não imaginei que causaria uma polêmica com essas proporções... Pessoal, quando lançei a pergunta sobre a questão do trust na verdade tinha duas preocupações: 1 - Proteger o patrimônio intelectual; 2 - Proteger o sistema contra a pirataria; A 2ª opção é possível contornar com sucesso. Mas a primeira parece que não é possível. O projeto de um banco de dados é algo muito valioso. O banco de dados é a parte mais importante de qualquer que seja o sistema. O modo como o banco é projetado, a lógica utilizada, os métodos utilizados para resolver os problemas de análise, tudo isso envolve muito investimento e pesquisa. Alguns podem achar loucura o que vou dizer, mas considero um projeto de banco de dados mais valioso do que qualquer código-fonte de qualquer aplicação que acesse esse mesmo banco de dados. Como o meu propósito é criar um sistema com fins comerciais, e sendo um sistema comercializado em modo de concessão de licença de uso, surgiu uma preocupação de como proteger esse patrimônio intelectual. Como não estou vendendo o meu projeto, estou apenas concedendo a licença de uso deste, não é nada interessante ver esse patrimônio exposto dessa maneira. Fico com a sensação de vender um software e entregar os fontes para o usuário. Imagine, você comprar o windows e vir junto os fontes... Conheço casos na justiça em que softhouses processaram pessoas que contrataram os seus sistemas, cancelaram o serviço, então pegaram o banco de dados e contrataram um programador para desenvolver uma aplicação que acesse esse banco de dados. Antes dar as caras novamente por aqui na discussão resolvi dar uma olhada nos outros SGDB's comerciais, e eles foram o Oracle e o DB2, os dois senhores dos SGDB's. Pude verificar que os dois tambem não oferecem autenticação a nível de banco, ou seja, novamente não é o DBA que dá a ultima palavra sobre quem pode ou não acessar o banco, é o administrador do servidor. Vendo que mesmo os SGDB's comerciais são dessa maneira, acho que fui infeliz ao fazer a pergunta que iniciou essa discussão. Talvez eu deveria ter sido mais claro nas minhas intenções. Peço desculpas. O problema não é o Postgres ou o Firebird. A filosofia dos SGDB's em geral é assim. Com relação aos SGDB's não há nada o que fazer. Mas de qualquer forma creio que a minha preocupação com o projeto do banco é algo bastante válido. Tanto é que na Europa existe legislação específica para tratar de proteção de direitos dos autores de projetos de banco de dados. Novamente agradeço a todos que participaram! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Voce poderia tambem gravar o pg_hba em cd/dvd/outro hd readonly, montar a unidade e iniciar o banco apontando para esse pg_hba. Nem root ia alterar. :) Thiago Bocchile On 2011 3 1 15:05, Leandro DUTRA leandro.gfc.du...@gmail.com wrote: 2011/3/1 Avelino Brun avel...@databrum.com.br: Como poderemos proteger os dados então pelos motivos que foram citados por você? Sabendo que não há nada simples em segurança, nem conveniente, a maneira mais simples é que somente os administradores de dados tenham os privilégios de superusuário e de DBA. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Olá! E quando for o servidor windows? Obrigado Avelino From: Thiago Bocchile Sent: Wednesday, March 02, 2011 7:53 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Voce poderia tambem gravar o pg_hba em cd/dvd/outro hd readonly, montar a unidade e iniciar o banco apontando para esse pg_hba. Nem root ia alterar. :) Thiago Bocchile On 2011 3 1 15:05, Leandro DUTRA leandro.gfc.du...@gmail.com wrote: 2011/3/1 Avelino Brun avel...@databrum.com.br: Como poderemos proteger os dados então pelos motivos que foram citados por você? Sabendo que não há nada simples em segurança, nem conveniente, a maneira mais simples é que somente os administradores de dados tenham os privilégios de superusuário e de DBA. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: mailto:xmpp%3aleand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Olha... eu digo que se a pessoa tem acesso root a maquina, não existe nada que possa fazer, no máximo encriptar os dados ao gravar na base pra dificultar a leitura direta. Não existe nada acima do root, ele pode exatamente TUDO. Marcelo Silva --- From: Avelino Brun Sent: Wednesday, March 02, 2011 8:50 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Olá! E quando for o servidor windows? Obrigado Avelino From: Thiago Bocchile Sent: Wednesday, March 02, 2011 7:53 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Voce poderia tambem gravar o pg_hba em cd/dvd/outro hd readonly, montar a unidade e iniciar o banco apontando para esse pg_hba. Nem root ia alterar. :) Thiago Bocchile On 2011 3 1 15:05, Leandro DUTRA leandro.gfc.du...@gmail.com wrote: 2011/3/1 Avelino Brun avel...@databrum.com.br: Como poderemos proteger os dados então pelos motivos que foram citados por você? Sabendo que não há nada simples em segurança, nem conveniente, a maneira mais simples é que somente os administradores de dados tenham os privilégios de superusuário e de DBA. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: mailto:xmpp%3aleand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Se você quer sigilo, cripografe os dados. Neste caso, mesmo que o root resolva espiar o que tem no BD, não vai conseguir ver nada. Em 1 de março de 2011 14:33, Avelino Brun avel...@databrum.com.brescreveu: Olá Alexander! Como poderemos proteger os dados então pelos motivos que foram citados por você? Atenciosamente Avelino *From:* Alexsander Rosa alexsander.r...@gmail.com *Sent:* Tuesday, March 01, 2011 12:53 PM *To:* Marcelo Silva (IG) marc...@ig.com.br ; Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br *Subject:* Re: [pgbr-geral]Como evitar autenticação trust? Há dois motivos para precisar disso: - sigilo (proteção dos dados contra acesso indevido) e - licenciamento (proteção do schema contra cópias indevidas) A criptografia só protege contra o primeiro caso. Nada impede que um administrador interessado em fazer cópias ilegais faça um DUMP do banco, com dados criptografados ou não, e instale em outro servidor. Em 28 de fevereiro de 2011 12:34, Marcelo Silva (IG) marc...@ig.com.brescreveu: Pense o seguinte... a segurança do banco depende da segurança do servidor, desta forma presume-se que se o cara tem acesso root ao servidor ele tem acesso ao que está nele. Existem algumas medidas drasticas a se tomar levando em conta a viabilidade, por exemplo, se não quer que acessem os arquivos de configurações do postgres terá que limitar o acesso as pastas somente ao usuario do postgres, essa configuração é dor de cabeça, pois as vezes o root precisa ter acesso a estas pastas pra no caso de ter que reinstalar o postgres e etc... então acaba não sendo viavel... Agora se o problema é alguém poder ler ou pegar os dados da tua base, você poderia gravar tudo encriptado, também não sei se seria o caso... mas são coisas a se pensar. Se a pessoa tem acesso direto a sua maquina... dificilmente irá conseguir bloquear os acessos a base... pois pra cada meio de segurança existem N meios de quebrar a segurança quando se tem acesso fisico a maquina. Acho que encriptar ainda é a medida mais aconselhavel quando não quer que alguem leia o que está ali. (claro que os fontes da aplicação que encripta deve estar muito bem guardado e longe do servidor) (acaba virando uma neorose rsrs ) Marcelo Silva --- -Mensagem Original- From: Leandro Guimarães Faria Corcete DUTRA Sent: Monday, February 28, 2011 12:01 PM To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Como evitar autenticação trust? On 2011.F.28 11h45, Fa wrote: Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? O pg_hba.conf somente pode ser editado pelo administrador, portanto não há problema algum. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa http://rednaxel.com -- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Olá! Me dá uma idéia de como posso encriptar os dados ao gravar. Atenciosamente Avelino From: Marcelo Silva (IG) Sent: Wednesday, March 02, 2011 8:58 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Olha... eu digo que se a pessoa tem acesso root a maquina, não existe nada que possa fazer, no máximo encriptar os dados ao gravar na base pra dificultar a leitura direta. Não existe nada acima do root, ele pode exatamente TUDO. Marcelo Silva --- From: Avelino Brun Sent: Wednesday, March 02, 2011 8:50 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Olá! E quando for o servidor windows? Obrigado Avelino From: Thiago Bocchile Sent: Wednesday, March 02, 2011 7:53 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Voce poderia tambem gravar o pg_hba em cd/dvd/outro hd readonly, montar a unidade e iniciar o banco apontando para esse pg_hba. Nem root ia alterar. :) Thiago Bocchile On 2011 3 1 15:05, Leandro DUTRA leandro.gfc.du...@gmail.com wrote: 2011/3/1 Avelino Brun avel...@databrum.com.br: Como poderemos proteger os dados então pelos motivos que foram citados por você? Sabendo que não há nada simples em segurança, nem conveniente, a maneira mais simples é que somente os administradores de dados tenham os privilégios de superusuário e de DBA. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: mailto:xmpp%3aleand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
2011/3/2 Avelino Brun avel...@databrum.com.br: Me dá uma idéia de como posso encriptar os dados ao gravar. Os dados podem ser cifrados pelo sistema operacional. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Para gravar encriptado é só fazer assim (a grosso modo):
Tabela Usuarios
nome
senha
Inserindo:
INSERT INTO Usuarios (nome, senha) VALUES (‘NOME DO USUARIO’, md5(‘12345’))
Alterando:
UPDATE Usuarios SET nome = ‘NOVO NOME’), senha= md5(‘67890’)
WHERE (nome = ‘NOME DO USUARIO’)
Veja a Função interna do Postgres “MD5” para Encriptar
Para pesquisar na base é só usar o MD5 tambem, veja:
SELECT * FROM Usuarios
WHERE (nome = ‘NOVO NOME’)
AND(senha = md5(‘67890’))
Para um simples execute esse simples SELECT e verá como ele irá gravar na base:
SELECT MD5('67890')
MD5 é uma função (hash) que não pode ser recuperada para o valor original,
desta forma ele é só de “ida” ou seja pra exibir em controle DBWare ou Edits
não é uma boa, pois fica ilegivel.
A melhor opção é criar sua propria função de encriptacao (embaralhamento) que
possa ser revertida no momento de exibir.
Sua função de encriptação terá uma chave (senha) que só você saberá, e por essa
“chave” poderá reverter o texto ou valor inserido na base.
O trabalho tem que justificar suas necessidades e vice versa.
Comentário:
Eu já peguei uma base de dados (Tabelas) em DBF que os dados mais importantes
eram todos encriptados por uma função no clipper, ou seja, mesmo em DBF é
praticamente impossivel ler a base sem os fontes originais.
Marcelo Silva
From: Avelino Brun
Sent: Wednesday, March 02, 2011 2:42 PM
To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Olá!
Me dá uma idéia de como posso encriptar os dados ao gravar.
Atenciosamente
Avelino
From: Marcelo Silva (IG)
Sent: Wednesday, March 02, 2011 8:58 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Olha... eu digo que se a pessoa tem acesso root a maquina, não existe nada que
possa fazer, no máximo encriptar os dados ao gravar na base pra dificultar a
leitura direta.
Não existe nada acima do root, ele pode exatamente TUDO.
Marcelo Silva
---
From: Avelino Brun
Sent: Wednesday, March 02, 2011 8:50 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Olá!
E quando for o servidor windows?
Obrigado
Avelino
From: Thiago Bocchile
Sent: Wednesday, March 02, 2011 7:53 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Voce poderia tambem gravar o pg_hba em cd/dvd/outro hd readonly, montar a
unidade e iniciar o banco apontando para esse pg_hba. Nem root ia alterar. :)
Thiago Bocchile
On 2011 3 1 15:05, Leandro DUTRA leandro.gfc.du...@gmail.com wrote:
2011/3/1 Avelino Brun avel...@databrum.com.br:
Como poderemos proteger os dados então pelos motivos que foram citados por
você?
Sabendo que não há nada simples em segurança, nem conveniente, a
maneira mais simples é que somente os administradores de dados tenham
os privilégios de superusuário e de DBA.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: mailto:xmpp%3aleand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql...
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Então galera, mas o que ele precisa é de uma forma de não alterarem o pg_hba
pelo que eu entendi, certo?
A idéia que eu dei anteriormente, usando um dispositivo READ ONLY para
colocar o pg_hba é valida, por mais que pareça uma gambiarra.
Essa idéia funciona tanto no Linux quanto no Windows, é só apontar para o
arquivo pg_hba.conf da unidade externa (pode ser CD/DVD/Hd externo com read
only ou meu favorito: unidade de rede, para windows).
Mesmo o cara sendo R00T M4573R, ele não vai conseguir alterar NADA no
arquivo, pois teoricamente, não da para gravar, correto?!
Bom, tenta ai a sugestão, mas como alguns colegas falaram: se tem gente com
acesso root, então não temos uma regra clara de segurança ai. ;)
*
Thiago Bocchile* *tyk...@gmail.com*
Linux User # 527010
http://about.me/tykoth
+551381318881
Em 2 de março de 2011 15:06, Marcelo Silva (IG) marc...@ig.com.brescreveu:
Para gravar encriptado é só fazer assim (a grosso modo):
Tabela Usuarios
nome
senha
Inserindo:
INSERT INTO Usuarios (nome, senha) VALUES (‘NOME DO USUARIO’, md5(‘12345’))
Alterando:
UPDATE Usuarios SET nome = ‘NOVO NOME’), senha= md5(‘67890’)
WHERE (nome = ‘NOME DO USUARIO’)
Veja a Função interna do Postgres “MD5” para Encriptar
Para pesquisar na base é só usar o MD5 tambem, veja:
SELECT * FROM Usuarios
WHERE (nome = ‘NOVO NOME’)
AND(senha = md5(‘67890’))
Para um simples execute esse simples SELECT e verá como ele irá gravar na
base:
SELECT MD5('67890')
MD5 é uma função (hash) que não pode ser recuperada para o valor original,
desta forma ele é só de “ida” ou seja pra exibir em controle DBWare ou Edits
não é uma boa, pois fica ilegivel.
A melhor opção é criar sua propria função de encriptacao (embaralhamento)
que possa ser revertida no momento de exibir.
Sua função de encriptação terá uma chave (senha) que só você saberá, e por
essa “chave” poderá reverter o texto ou valor inserido na base.
O trabalho tem que justificar suas necessidades e vice versa.
Comentário:
Eu já peguei uma base de dados (Tabelas) em DBF que os dados mais
importantes eram todos encriptados por uma função no clipper, ou seja, mesmo
em DBF é praticamente impossivel ler a base sem os fontes originais.
Marcelo Silva
From: Avelino Brun
Sent: Wednesday, March 02, 2011 2:42 PM
To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Olá!
Me dá uma idéia de como posso encriptar os dados ao gravar.
Atenciosamente
Avelino
From: Marcelo Silva (IG)
Sent: Wednesday, March 02, 2011 8:58 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Olha... eu digo que se a pessoa tem acesso root a maquina, não existe nada
que possa fazer, no máximo encriptar os dados ao gravar na base pra
dificultar a leitura direta.
Não existe nada acima do root, ele pode exatamente TUDO.
Marcelo Silva
---
From: Avelino Brun
Sent: Wednesday, March 02, 2011 8:50 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Olá!
E quando for o servidor windows?
Obrigado
Avelino
From: Thiago Bocchile
Sent: Wednesday, March 02, 2011 7:53 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral]Como evitar autenticação trust?
Voce poderia tambem gravar o pg_hba em cd/dvd/outro hd readonly, montar a
unidade e iniciar o banco apontando para esse pg_hba. Nem root ia alterar.
:)
Thiago Bocchile
On 2011 3 1 15:05, Leandro DUTRA leandro.gfc.du...@gmail.com wrote:
2011/3/1 Avelino Brun avel...@databrum.com.br:
Como poderemos proteger os dados então pelos motivos que foram citados
por
você?
Sabendo que não há nada simples em segurança, nem conveniente, a
maneira mais simples é que somente os administradores de dados tenham
os privilégios de superusuário e de DBA.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: mailto:xmpp%3aleand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql...
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr
Re: [pgbr-geral] Como evitar autenticação trust?
Em 02/03/11, Thiago Bocchiletyk...@gmail.com escreveu: Então galera, mas o que ele precisa é de uma forma de não alterarem o pg_hba pelo que eu entendi, certo? A idéia que eu dei anteriormente, usando um dispositivo READ ONLY para colocar o pg_hba é valida, por mais que pareça uma gambiarra. Essa idéia funciona tanto no Linux quanto no Windows, é só apontar para o arquivo pg_hba.conf da unidade externa (pode ser CD/DVD/Hd externo com read only ou meu favorito: unidade de rede, para windows). Mesmo o cara sendo R00T M4573R, ele não vai conseguir alterar NADA no arquivo, pois teoricamente, não da para gravar, correto?! Bom, tenta ai a sugestão, mas como alguns colegas falaram: se tem gente com acesso root, então não temos uma regra clara de segurança ai. ;) * Repare que o usuário com poderes de super-usuário pode modificar o local do arquivo pg_hba.conf [1], dar um restart do PostgreSQL e dessa forma liberar qualquer tipo de acesso. Creio que a grande falha de segurança é a existência, indevida, de usuários com poderes que não deveriam ter. Se você deu a chave de sua casa a um ladrão então não pode reclamar de ter sido roubado. Osvaldo [1] http://www.postgresql.org/docs/current/interactive/runtime-config-file-locations.html ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Em 2 de março de 2011 17:36, Osvaldo Kussama osvaldo.kuss...@gmail.com escreveu: Repare que o usuário com poderes de super-usuário pode modificar o local do arquivo pg_hba.conf [1], dar um restart do PostgreSQL e dessa forma liberar qualquer tipo de acesso. Creio que a grande falha de segurança é a existência, indevida, de usuários com poderes que não deveriam ter. Se você deu a chave de sua casa a um ladrão então não pode reclamar de ter sido roubado. Osvaldo [1] http://www.postgresql.org/docs/current/interactive/runtime-config-file-locations.html A segurança do banco de dados se baseia em 2 práticas impreteríveis: 1) não dar acesso de root a quem não merece; 2) restringir o acesso ao servidor físico (isso mesmo ao hardware) somente aos administradores. Certa vez eu não tinha acesso aos arquivos de configuração do servidor em um cliente. Mas tinha acesso ao servidor físico. Mudei alguns parâmetros no GRUB [1], e... Voilá! Consegui alterar a senha do root. Só para que fique registrado: outros SGBDs utilizam os protocolos de segurança (por assim se dizer) do sistema operacional, como o IBM DB2. Tendo a senha do root ou administrator, você toma conta de tudo. [1] http://www.debuntu.org/recover-root-password-single-user-mode-and-grub -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Há dois motivos para precisar disso: - sigilo (proteção dos dados contra acesso indevido) e - licenciamento (proteção do schema contra cópias indevidas) A criptografia só protege contra o primeiro caso. Nada impede que um administrador interessado em fazer cópias ilegais faça um DUMP do banco, com dados criptografados ou não, e instale em outro servidor. Em 28 de fevereiro de 2011 12:34, Marcelo Silva (IG) marc...@ig.com.brescreveu: Pense o seguinte... a segurança do banco depende da segurança do servidor, desta forma presume-se que se o cara tem acesso root ao servidor ele tem acesso ao que está nele. Existem algumas medidas drasticas a se tomar levando em conta a viabilidade, por exemplo, se não quer que acessem os arquivos de configurações do postgres terá que limitar o acesso as pastas somente ao usuario do postgres, essa configuração é dor de cabeça, pois as vezes o root precisa ter acesso a estas pastas pra no caso de ter que reinstalar o postgres e etc... então acaba não sendo viavel... Agora se o problema é alguém poder ler ou pegar os dados da tua base, você poderia gravar tudo encriptado, também não sei se seria o caso... mas são coisas a se pensar. Se a pessoa tem acesso direto a sua maquina... dificilmente irá conseguir bloquear os acessos a base... pois pra cada meio de segurança existem N meios de quebrar a segurança quando se tem acesso fisico a maquina. Acho que encriptar ainda é a medida mais aconselhavel quando não quer que alguem leia o que está ali. (claro que os fontes da aplicação que encripta deve estar muito bem guardado e longe do servidor) (acaba virando uma neorose rsrs ) Marcelo Silva --- -Mensagem Original- From: Leandro Guimarães Faria Corcete DUTRA Sent: Monday, February 28, 2011 12:01 PM To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Como evitar autenticação trust? On 2011.F.28 11h45, Fa wrote: Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? O pg_hba.conf somente pode ser editado pelo administrador, portanto não há problema algum. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Olá Alexander! Como poderemos proteger os dados então pelos motivos que foram citados por você? Atenciosamente Avelino From: Alexsander Rosa Sent: Tuesday, March 01, 2011 12:53 PM To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral]Como evitar autenticação trust? Há dois motivos para precisar disso: - sigilo (proteção dos dados contra acesso indevido) e - licenciamento (proteção do schema contra cópias indevidas) A criptografia só protege contra o primeiro caso. Nada impede que um administrador interessado em fazer cópias ilegais faça um DUMP do banco, com dados criptografados ou não, e instale em outro servidor. Em 28 de fevereiro de 2011 12:34, Marcelo Silva (IG) marc...@ig.com.br escreveu: Pense o seguinte... a segurança do banco depende da segurança do servidor, desta forma presume-se que se o cara tem acesso root ao servidor ele tem acesso ao que está nele. Existem algumas medidas drasticas a se tomar levando em conta a viabilidade, por exemplo, se não quer que acessem os arquivos de configurações do postgres terá que limitar o acesso as pastas somente ao usuario do postgres, essa configuração é dor de cabeça, pois as vezes o root precisa ter acesso a estas pastas pra no caso de ter que reinstalar o postgres e etc... então acaba não sendo viavel... Agora se o problema é alguém poder ler ou pegar os dados da tua base, você poderia gravar tudo encriptado, também não sei se seria o caso... mas são coisas a se pensar. Se a pessoa tem acesso direto a sua maquina... dificilmente irá conseguir bloquear os acessos a base... pois pra cada meio de segurança existem N meios de quebrar a segurança quando se tem acesso fisico a maquina. Acho que encriptar ainda é a medida mais aconselhavel quando não quer que alguem leia o que está ali. (claro que os fontes da aplicação que encripta deve estar muito bem guardado e longe do servidor) (acaba virando uma neorose rsrs ) Marcelo Silva --- -Mensagem Original- From: Leandro Guimarães Faria Corcete DUTRA Sent: Monday, February 28, 2011 12:01 PM To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Como evitar autenticação trust? On 2011.F.28 11h45, Fa wrote: Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? O pg_hba.conf somente pode ser editado pelo administrador, portanto não há problema algum. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
2011/3/1 Avelino Brun avel...@databrum.com.br: Como poderemos proteger os dados então pelos motivos que foram citados por você? Sabendo que não há nada simples em segurança, nem conveniente, a maneira mais simples é que somente os administradores de dados tenham os privilégios de superusuário e de DBA. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Como evitar autenticação trust?
Bom Dia, Pessoal, sou novato no Postgres, e trago uma dúvida que já foi muito discutida por ai, só que não encontrei nada conclusivo. Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? É possível desativar esse tipo de autenticação durante a instalação do servidor, para que assim mesmo que o pg_hba.conf seja alterado esse modo não esteja disponível? Não há como estabelecer esse tipo de segurança sem depender de fatores externos ao SGDB, como por exemplo, sem depender da configuração do SO para restringir quem pode ou não acessar o arquivo de configuração? já trabalhei com firebird e ele tem um problema parecido: basta que alguem copie o arquivo de banco de dados e leve para outra máquina, instale o firebird, e como na instalação a senha do super-usuário é conhecida, ele tem acesso completo a todo o banco de dados. caso não haja solução para o problema do Postgres gostaria de saber se esse problema ocorre somente nos SGDB's OpenSource ou se os SGDB's comerciais, como o Oracle ou o SQL Server tambem são assim, tendo sua segurança dependentes do sistema operacional, bastando a pessoa ter acesso ao servidor para conseguir acessar qualquer banco de dados, seja alterando algum arquivo de configuração ou seja copiando os arquivos do banco e levando para outro computador. obrigado -- View this message in context: http://postgresql.1045698.n5.nabble.com/Como-evitar-autenticacao-trust-tp3403354p3403354.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
On 2011.F.28 11h45, Fa wrote: Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? O pg_hba.conf somente pode ser editado pelo administrador, portanto não há problema algum. attachment: leandro_gfc_dutra.vcf___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
2011/2/28 Fa fsa...@gmail.com: Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? SGBD significa Sistema de gerenciamento de banco de dados e não Sistema de proteção ou inviolabilidade dos dados. É possível desativar esse tipo de autenticação durante a instalação do servidor, para que assim mesmo que o pg_hba.conf seja alterado esse modo não esteja disponível? Há mais semelhanças entre armazenar dados em um SGBD e um arquivo de texto do que você pode perceber. Os dados continuarão no diretório de dados (ex: /var/lib/postgres), e apesar do padrão de armazenamento utilizado por um SGBD, é apenas uma notação formato, assim como um CSV. Não há como estabelecer esse tipo de segurança sem depender de fatores externos ao SGDB, como por exemplo, sem depender da configuração do SO para restringir quem pode ou não acessar o arquivo de configuração? Novamente, SGBD significa Sistema de gerenciamento de banco de dados e não Sistema de proteção ou inviolabilidade dos dados. já trabalhei com firebird e ele tem um problema parecido: basta que alguem copie o arquivo de banco de dados e leve para outra máquina, instale o firebird, e como na instalação a senha do super-usuário é conhecida, ele tem acesso completo a todo o banco de dados. Isto não é um problema para um SGDB. caso não haja solução para o problema do Postgres gostaria de saber se esse problema ocorre somente nos SGDB's OpenSource ou se os SGDB's comerciais, como o Oracle ou o SQL Server tambem são assim, tendo sua segurança dependentes do sistema operacional, Idem. bastando a pessoa ter acesso ao servidor para conseguir acessar qualquer banco de dados, seja alterando algum arquivo de configuração ou seja copiando os arquivos do banco e levando para outro computador. Dados são apenas dados. -- Reinaldo de Carvalho http://korreio.sf.net http://python-cyrus.sf.net While not fully understand a software, don't try to adapt this software to the way you work, but rather yourself to the way the software works (myself) ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Pessoal, sou novato no Postgres, e trago uma dúvida que já foi muito discutida por ai, só que não encontrei nada conclusivo. Sim, sua dúvida é totalmente conclusiva. Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? Aí é que está sua má interpretação: o arquivo pg_hba.conf, por padrão, só pode ser alterado pelo usuário postgres ou root, que você deve permitir acesso somente a alguns usuários. Se você possui administradores de sistema, o acesso a esses usuários só pode ser confiado a eles. Se você não confia nem neles, dê poderes de sudo restritos para quem pode mexer aí (mas reveja seus conceitos de quem pode ou não fazer as coisas). É possível desativar esse tipo de autenticação durante a instalação do servidor, para que assim mesmo que o pg_hba.conf seja alterado esse modo não esteja disponível? Só alterando o código fonte. Não há como estabelecer esse tipo de segurança sem depender de fatores externos ao SGDB, como por exemplo, sem depender da configuração do SO para restringir quem pode ou não acessar o arquivo de configuração? Sim. É exatamente aí que você pode atuar. já trabalhei com firebird e ele tem um problema parecido: basta que alguem copie o arquivo de banco de dados e leve para outra máquina, instale o firebird, e como na instalação a senha do super-usuário é conhecida, ele tem acesso completo a todo o banco de dados. caso não haja solução para o problema do Postgres gostaria de saber se esse problema ocorre somente nos SGDB's OpenSource ou se os SGDB's comerciais, como o Oracle ou o SQL Server tambem são assim, tendo sua segurança dependentes do sistema operacional, bastando a pessoa ter acesso ao servidor para conseguir acessar qualquer banco de dados, seja alterando algum arquivo de configuração ou seja copiando os arquivos do banco e levando para outro computador. Esse problema no PostgreSQL não existe. Os arquivos de dados são de propriedade do usuário postgres (numa instalação convencional) e ninguém mais pode nem mesmo listar o diretório. Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Pense o seguinte... a segurança do banco depende da segurança do servidor, desta forma presume-se que se o cara tem acesso root ao servidor ele tem acesso ao que está nele. Existem algumas medidas drasticas a se tomar levando em conta a viabilidade, por exemplo, se não quer que acessem os arquivos de configurações do postgres terá que limitar o acesso as pastas somente ao usuario do postgres, essa configuração é dor de cabeça, pois as vezes o root precisa ter acesso a estas pastas pra no caso de ter que reinstalar o postgres e etc... então acaba não sendo viavel... Agora se o problema é alguém poder ler ou pegar os dados da tua base, você poderia gravar tudo encriptado, também não sei se seria o caso... mas são coisas a se pensar. Se a pessoa tem acesso direto a sua maquina... dificilmente irá conseguir bloquear os acessos a base... pois pra cada meio de segurança existem N meios de quebrar a segurança quando se tem acesso fisico a maquina. Acho que encriptar ainda é a medida mais aconselhavel quando não quer que alguem leia o que está ali. (claro que os fontes da aplicação que encripta deve estar muito bem guardado e longe do servidor) (acaba virando uma neorose rsrs ) Marcelo Silva --- -Mensagem Original- From: Leandro Guimarães Faria Corcete DUTRA Sent: Monday, February 28, 2011 12:01 PM To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Como evitar autenticação trust? On 2011.F.28 11h45, Fa wrote: Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? O pg_hba.conf somente pode ser editado pelo administrador, portanto não há problema algum. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como evitar autenticação trust?
Em 28 de fevereiro de 2011 12:01, Leandro Guimarães Faria Corcete DUTRA leandro.gfc.du...@gmail.com escreveu: On 2011.F.28 11h45, Fa wrote: Como proteger um banco de dados Postgres contra acesso indevido, sendo que basta qualquer um alterar o arquivo de configuração pg_hba.conf colocando o modo de autenticação trust no servidor para conseguir acesso total ao servidor Postgres inclusive como super-usuário sem informar senha alguma? O pg_hba.conf somente pode ser editado pelo administrador, portanto não há problema algum. Eu sempre prego a filosofia de ter um servidor dedicado para o banco de dados. Em servidores *multi-tarefa*, principalmente Window$, isto quase sempre não é realidade (i.e. vários usuários com direitos de administrador). O *x* da questão é ser incisivo neste ponto: somente O administrador (e não um grupo) pode ter acesso aos arquivos de configuração, além do usuário *postgres*. -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
