|
acastanheira2001 12/02/2009, 14:03 Pessoal,
Que controles aplicar, que estrutura devo ter, de forma minimizar o risco dos dba´s acessarem os dados de produção?
Vocês sabem me dizer se os dba´s necessitam acessar os dados de produção? Será que existe alguma atividade do dia-a-dia que requeira este privilégio?
De outra forma. Será que o DBA consegue trabalhar sem ter acesso aos dados?
Existem melhores práticas a respeito?
Obrigado,
André
Pessoal,
Que controles aplicar, que estrutura devo ter, de forma minimizar o risco dos dba´s acessarem os dados de produção?
Vocês sabem me dizer se os dba´s necessitam acessar os dados de produção? Será que existe alguma atividade do dia-a-dia que requeira este privilégio?
De outra forma. Será que o DBA consegue trabalhar sem ter acesso aos dados?
Existem melhores práticas a respeito?
Obrigado,
André
Se quer esconder algo do DBA, cifre os dados. Claro, usando uma chave que não esteja armazenada na própria BD, e não esteja acessível ao DBA, ou seja, cifre e decifre na ponta do cliente, não através de funções que o próprio SGBD eventualmente forneça.
Quanto as perguntas de "se o DBA precisa ter acesso", isso vai depender o que tudo seu DBA faz além de ser realmente um DBA, e depende de que dados são esses, e assim por diante. Mas considerando que você não quer que ele veja os dados, 99% de certeza que a resposta seja "não, ele não precisa desses dados".
J.Augusto 12/02/2009, 21:40 Não entendi...
Se o DBA não precisa dos dados, ele então não é uma DBA, mas, alguém que está realizando o papel de um em alguma função, sendo assim então só um programador, pq não se tem DBA no setor... Penso assim.
DBA já diz tudo ele é o administrador, como ele vai exercer a função com acesso retrito? Quem precisa ter retrições de acesso não é o DBA mas o povo da fábrica de software. ;)
Com corda? Ou sem corda?
Hmmm... acho que sem corda pra mim ;)
Um DBA sempre terá acesso irrestrito aos dados. Mas não precisa ter acesso à informação. Basta, como disse, cifrá-la, e isso me parece que em nada (ou pouco) atrapalha e restringe as funções de um DBA.
Isso é claro precisa de critério, não vai se cifrar tudo, mas sim o que é crítico a ponto de nem o DBA poder ter acesso. Cifragem e decifragem no lado do cliente, dado a dado, pode ser custoso demais.
Pois vejamos, algumas funções de um DBA, segundo a wikipedia:
* Instalação e Upgrade de SGBD - Não precisa de acesso às informações
* Gerenciamento de usuários - Não precisa de acesso às informações
* Design e Otimizações das tabelas - Pode usar as informações, mas aí vai da prioridade que tem a privacidade
Mas dá pra apelar pra coisas mais simples também e ajudar a resolver os desafios de diminuir o "poder" do DBA. Por exemplo, selecionar 2 ou 3 pessoas e cada um fica com uma parte da senha, que só essa pessoa conhece (ele que digitou). Vai ter o trabalho de, quando tiver uma função administrativa a ser executada, ter q contar com os 2 ou 3 pessoas pra digitar a senha, mas se precisa de mais confiança e sua aplicação é assim crítica, é uma opção. As senhas deixa também no cofre da empresa, em envelopes lacrados, pra qualquer emergência serem utilizados.
Como disse... vai depender do cenário e de que tipo de informação você quer preservar, com que criticidade, etc.
J.Augusto 12/02/2009, 22:12 Oi Birk! Obg por responder.
Bom, na minha vivencia, vejo muitos casos de se precisar alterar conteúdos das tabelas dos bancos, parece mentira mas é vero... Por isto comigo fica com a corda mesmo rs... Mtas vezes, decisões da alta gerencia determinam o que vai ser mudado e com urgencia, sabe D_us pq mas acontece, e se tiver mtos impecílios pelo meio do caminho, cabeças rolam, e não pode ser a do DBA ;)
Abração!
Oi Birk! Obg por responder.
Bom, na minha vivencia, vejo muitos casos de se precisar alterar conteúdos das tabelas dos bancos, parece mentira mas é vero... Por isto comigo fica com a corda mesmo rs... Mtas vezes, decisões da alta gerencia determinam o que vai ser mudado e com urgencia, sabe D_us pq mas acontece, e se tiver mtos impecílios pelo meio do caminho, cabeças rolam, e não pode ser a do DBA ;)
Abração!
Ah bom... Desculpe minha vivência acadêmica, vivendo de estudar cenários ideais hehehehehe ;)
Digamos assim: isso não devia acontecer. Especialmente em dados tão críticos que, pelo autor do tópico, nem mesmo o DBA deve ver.
Mas fica difícil conjecturar pois não sabemos se o cenário dele é desse tipo que apresentas. Espero que não seja, pq dados críticos precisando de modificações on the fly pelo DBA parece um tanto... assustador! hehehehe
jbonagura 14/02/2009, 01:27 Pessoal
Boa Noite, tudo blz?
Sou novo por aqui, e para ser sincero não sou um grande conhecedor de BD, porém gostaria de comentar e até mesmo solicitar uma ajuda(explicação) do Birkoff se possível.
Entendo quando o J. Augusto fala que muitas vezes temos um cenário onde existam alterações constantes de sistemas e como conseguência do BD. Trabalhei durante alguns anos em uma empresa onde tinham um sistema de ERP interno que sofria diversas atualizações e sempre eram emergenciais.
Apesar de entender não concordo com este tipo de execução, acredito que deveriam entrar primeiramente em um ambiente de teste, passar por todo um processo e ai sim ocorrer, mas como o J. Augusto mesmo disse cabeças rolam e as coisas acontecem...
Mas vamos lá, se puderem me ajudar nesta explicação:
Bikoff, quando você fala que o DBA tem as seguintes funções:
* Instalação e Upgrade de SGBD - Não precisa de acesso às informações
* Gerenciamento de usuários - Não precisa de acesso às informações
* Design e Otimizações das tabelas - Pode usar as informações, mas aí vai da prioridade que tem a privacidade
Ele necessariamente tem que ter um acesso de "Administrador , root , super usuário" correto? Se sim, ele já tem tudo o que precisa em mãos para visualizar estes dados, correto? Ou a sua idéia seria de ter os dados criptografados no Banco e descriptografar na aplicação? Isso seria viável? Existe algo trabalhando assim? pois acredito ser interessante principalmente pensando em dados que trafegam via sistema web, ou seja além do ssl dá página ou dados do BD também estariam...
Enfim, me ajudem a entender um pouco melhor isso!
Obrigado
Abs
(...)Ou a sua idéia seria de ter os dados criptografados no Banco e descriptografar na aplicação? Isso seria viável? Existe algo trabalhando assim? pois acredito ser interessante principalmente pensando em dados que trafegam via sistema web, ou seja além do ssl dá página ou dados do BD também estariam...
Enfim, me ajudem a entender um pouco melhor isso!
Sim, exatamente. Se você não confia no DBA, terá que implementar a cifragem em "client side". Viável é, não é muito prático e eficiente. Mas se teus dados são sigilosos a esse ponto...
Mas eu acho que dados sigilosos a esse ponto NÃO deveriam sofrer interferência direta do DBA também. Dados importantes merecem uma BD bem desenhada. E se não vai precisar de interferência do DBA, cifragem em server side e uma boa senha "compartilhada" do DBA, só para emergências, resolveriam o problema.
PS: Acredito que parte das nossas eventuais divergências também provavelmente são fruto da diferença de visão de que funções realmente são de um DBA. O que se vê na prática é que o DBA acumula muitas funções diferentes.
PS2: Não sou especialista em BD ;)... Meu conhecimento se restringe a uma matéria da faculdade e um pouco de experiência prática. Por favor, considerem isso ao ler minhas opiniões hehehe
J.Augusto 14/02/2009, 12:20 (...)Entendo quando o J. Augusto fala que muitas vezes temos um cenário onde existam alterações constantes de sistemas e como conseguência do BD. Trabalhei durante alguns anos em uma empresa onde tinham um sistema de ERP interno que sofria diversas atualizações e sempre eram emergenciais.(...) - Não foi isto que falei, não falei em momento algum em um cenário que exista alterações constantes de sistemas, falei sim, que acontece de se ter alterações nas tabelas do BD, por exigência da alta gerência e muitas vezes como por exemplo, em sistemas que envolvem orçamentos, diárias e etc, até mesmo para re-cobrir buracos de implementações anteriomente utilizadas. E isto eu já vi acontecer mtas vezes... Principalmente quando o sistema é implementado para ter controle a partir de um momento onde outrora se tinha um rombo (orçamentário como por exemplo) nunca vi mudanças em dados de um BD de ERP.
As mudanças que citei são de sistemas internos, elaborados dentro do embiente empresarial, na fábrica de software, aí sim podemos ter eventuais modificações. Diga-se de passagem, tanto no código do sistema, como no BD.
Sistemas tipo comprados 'caixa preta' nunca vi fazer isto.
Já vivenciei mto acontecer correções nos sistemas quando estão sendo implementados.
Um outro exemplo disto, é ter um sistema de gerência de férias de funcionários públicos. Vc não vai alterar o sistema constantemente, pq o estatuto do funcionalismo público não vive sendo alterado então...
Outro exemplo é se ter um sistema que discipĺina o uso das faixas de domínio das rodovias estaduais, (este tipo é bem recente), o BD deste não poderá sofrer modificações constantes, pois a lei que o rege, não tem previsões para modificações...
Se fosse assim, para se modificar constantemente, seria preciso sempre se modificar as regulamentações que regem o que o sistema se baseia.
É isso aí..
[]'s
jbonagura 14/02/2009, 14:03 J. Augusto, entendi o que você quis dizer agora, porém realmente trabalhei em uma organização, onde os programadores e até mesmo os dirigentes da empresa faziam constantes alterações no sistema e consequentemente em tabelas do banco de dados, o que na minha opinião é uma loucura...
Birkoff, obrigado pelos esclarecimentos, acredito que apesar de diminuir a performance, pode ser uma boa solução em alguns sistemas específicos.
Pessoal, obrigado pelos esclarecimentos e espero que possamos discutir mais sobre outros assuntos e assim enriquecer conhecimentos, neste caso, principalmente o meu, rsrsr, porém tenho certeza que em algumas áreas poderei também contribuir
Abs
acastanheira2001 16/02/2009, 09:35 Pessoal,
Em primeiro lugar, obrigado pela grande discussão acerca do tópico que criei.
Em segundo lugar, entendo que o DBA não deveria, em tese, ter acesso aos dados visto que suas funções estão relacionadas a:
Manter o banco de dados funcionando conforme o SLA do negócio;
Controle de acesso adequado, caso este controle esteja "nas mãos" do dba;
Garantir a continuidade por meio de backup, redundância, etc....
Análise de performance de acesso aos dados. {Este item poderia necessitar acesso aos dados}
De forma a administrar o BD, o DBA necessita utilizar usuários privilegiados.
Teriocamente, somente a aplicação deveria "ver" o dado.
Infelizmente, a alteração emergencial da base de dados é um evento que deveria ser minimizado ao máximo.
Estamos tentando avaliar o processo "Administração de Banco de Dados" com foco em segurança de forma a melhorar nossos controles.
Obs: A base contém alguns dados sensíveis.
Mais uma vez obrigado pela discussão.
Todo o DBA é responsável pelas informações do BD, creio que para esta responsabilidade, o certo será utilizar um termo de responsabilidade especifico para o DBA e administradores de sistemas. Olhem um trecho da normativa que estamos criando para os administradores.
CAPÍTULO II
DO ACESSO PRIVILEGIADO
Art 7.º Os Administradores de Serviço deverão fazer uso dos acessos privilegiados aos ativos disponibilizados, de acordo com os procedimentos em vigor.
§ 1º. Os Administradores de Serviço terão acesso privilegiado unicamente aos ativos que forem indispensáveis à realização de suas atividades, cabendo à SGI a administração destas concessões.
§ 2°. É vedada a utilização do acesso privilegiado pelos Administradores de Serviço para fins diferentes àqueles que justificaram sua concessão.
§ 3°. A utilização indevida dos privilégios a que se refere este artigo é de responsabilidade do
Administrador de Serviço, como também são as conseqüências dela decorridas
Desta forma, se o DBA se beneficiar de informações sigilosas, estara infringindo uma norma, e conseqüentemente sofrera a punição.
|
|
