none
Segurança e organização RRS feed

  • Pergunta

  • Olá amigos,

    lembra aquela velha historia que cada 1 cria uma base para sua aplicação, logo v fic cheio de banco de dados pequeno??
    Essa é nova realidade, olh os bancos:

    = CPD, AlunoOnline, Extranet, NOTES, Curriculo, IOL; acho que só estes...

    São bancos com poucas informações mais que da um custo de manutenção chato.
    Backup, due ____ servidor, recuperar informação para restaurar etc.

    Então pensei, já que ests bases é administrado por nós do CPD como suas aplicações,
    então pq não unir??

    Lembro que posso utilizar shemmas, usuarios especifico para cada aplicativo e permissões especificas:

    tabelas da extranet: shemas "ext"
    exemplo: ext.noticias

    tabelas da NOTES: shemas "not"
    exemplo: not.notas, not.avaliacao

    regra de shema seria as 3 primeiras letras do nome do aplicativo.
    agora questão de permissão, cada usuario exemplo:
    usuario: uextranet teria permissão de insert, update, delete apenas sobre o shema "ext"
    Não poderia acessar o outros shema, só se for dado permissão a certas tabelas;

    COm isso garanto a segurança se alguem consegui invadir o BD atraves de alguma falha do aplicativo especifico, não ter acesso a toda informação.

    Alguem pode me ajudar com isso?

    Obrigado a todos,
    Forte abraço






    Att, Luiz Anderson - Programador DOTNET, Administrador SQL SERVER 2005
    • Movido Gustavo Maia Aguiar quarta-feira, 5 de agosto de 2009 22:15 (De:SQL Server - Desenvolvimento Geral)
    quarta-feira, 29 de julho de 2009 12:25

Respostas

  • Anderson imagino o seguinte cenário:

    1 - Criar um schema para cada aplicação
      EX: cpd, aluno, Extranet, notes, Curriculo, iol >>>> na minha opnião não precisa deixar um tamanho fixo o nome do schema e sim um valor que realmente   expresse sua aplicação

    2 - Criar um login e usuário para cada aplicação
      EX: SI$CPD, SI$ALUNO, SI$EXTRANET........ obs: lembre de colocar o default schema correto para cada usuário ex:> Para o usuário SI$CPD o schema será o cpd

    3 - Como você só terá um usuário por aplicação você poderia já dar as permissões no schema diretamente para o usuário, mas já pensando no futuro, mesmo por enquanto tendo apenas um usuário por aplicação crie um ROLE para cada aplicação, assim no futuro se surgir novos usuários só inclui-los na role.
      EX: RO_CPD, RO_ALUNO, RO_EXTRANET........ No onwer de cada role coloque um login com poderes Sysadmin, pode usar o mesmo para todas as roles a mesma coisa para os schemas.

    4 - Dar as permissões DML(INSERT, UPDATE, DELETE, SELECT, EXECUTE E ALTER) NO SCHEMA CORRESPONDETE A ROLE CRIADA.
      EX: Na role RO_CPD você seleciona em securables o schema SI$CPD e da grant nas permissões acima, da mesma forma para as outras roles.

    5 - Em cada ROLE adiciona o usuário criado para aplicação do schema associado a role.
      ex: Na role RO_CPD em Role Members adicione somente o SI$CPD e assim por diante paras as outras roles.

    Para solucionar o problema da tabela corporativa de usuários, você pode criar um role por ex chamada CORP_SEL com permissão apenas de SELECT na tabela de usuários e não no schema inteiro, apenas nesta tabela específica. Adicione em members desta role todas as outras roles das aplicações que precisarem realizar select nesta tabela, assim além das permissões apenas no schema associado as roles também terão permissão de select nesta tabela.

    Cria uma outra role CORP_UPD com permissão de update na tabela de usuários e adicione no members desta role, todas as roles que devem ter permissão de update nesta tabela.

    acho que desta forma se torna possível realizar manutenções futuras sem impacto no schema.

    esclareceu algo, ou ainda tem dúvidas? 
    DBA SQL Server MCTS - SQL Server 2005 | ITIL Foundation V2 http://www.bydocs.com
    • Sugerido como Resposta Fernanda Simões terça-feira, 4 de agosto de 2009 14:12
    • Marcado como Resposta anderson s. dias sexta-feira, 25 de setembro de 2009 12:32
    quinta-feira, 30 de julho de 2009 17:32

Todas as Respostas

  • Luiz,

    Me desculpe mas não consegui entender o que você deseja fazer.


    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quarta-feira, 29 de julho de 2009 15:10
    Moderador
  • Olá Junior,


    Tenho uns 4 aplicativos cda ql com sua base de dados e todos os seus objetos.

    QUero integrar todos em um unica base de dados e determinar uma politica de previlegios para arantir que se for invadido uma aplicação com o usuario dele, não irá afear as tabelas dos outros sistema desde que estão em um unica base de dados.

    Abaço

    Att, Luiz Anderson - Programador DOTNET, Administrador SQL SERVER 2005
    quarta-feira, 29 de julho de 2009 17:46
  • Anderson, normalmente união de banco de dados é recomendado apenas para banco de dados com informações corporativas, assim quando em um ambiente vc possui várias aplicações onde se utilizam informações em comum criamos essas tabelas em um banco de dados coorporativo, não sei se o que pensa em fazer seria a melhor solução, a não ser que uma aplicação realmente esteja relacionada a outra.   

    Da mesma forma que pode ajudar em alguns casos pode também dar mais trabalho em outros, deixando tudo em um só vc está mais propicio a problemas, se der problema em um banco para todas as aplicações e não ser que vc separe cada schema em um filegroup vc não consegue fazer backup por schema e nem restaurar apenas tabelas de uma determinada aplicação, tendo assim que parar todas as aplicações para fazer um restore e assim por diante.

    mas ai vai da sua necessidade se realmente achar interessante, a separação por schema seria a correta, te daria um pouco de trabalho para montar todo o schema mas é possível.

    boa sorte.
    DBA SQL Server MCTS - SQL Server 2005 | ITIL Foundation V2 http://www.bydocs.com
    quarta-feira, 29 de julho de 2009 17:57
  • Olá Clayton, é praticamente integrado, maos lá: banco CPD - tem dados: sistema SGI - onde é desktop e também a nossa extranet consome. Tabela com dados de funcionarios par autenticaçõs. banco: extranet - tem dados: sistema web extranet - todas as tabelas estao neste banco. Para se autenticar necessita da tabela usuario que esta no banco CPD. Tem tb todos os objetos do sistema Web NOTES que tb verifica se o funcionario existi na tabela usuario do banco CPD. sistema NOTES - tb utiliza tebelas do sistema IOL. banco IOL - tem dados: sistema eb IOL - todos as inscrições para empresa. O funcionario se autentica na tabela usuario do CPD. entre outras relações;
    Att, Luiz Anderson - Programador DOTNET, Administrador SQL SERVER 2005
    quarta-feira, 29 de julho de 2009 18:33
  • Se realmente for dividir a sua idéia está coerente, dividir em schemas, criar roles com as permissões, associar os usuários as roles e as roles ao schema. Só que na aplicação vc terá que mudar todas as queries para schema.tabela e não apenas tabela que normalmente é usado no schema dbo.

    tem alguma dúvida referente a segurança? 
    DBA SQL Server MCTS - SQL Server 2005 | ITIL Foundation V2 http://www.bydocs.com
    quarta-feira, 29 de julho de 2009 18:52
  • Olá Cleyton,

    ontem sentei com meu colega de trabalho para apresentar um levantamento que fiz sobre segurança, desempenho e perca de tempo na realização dos backup.

    Apresentei a necessidade de modificar a nossa estrutura para se adequar um ambiente seguro e integrado.
    Também salientei sobre o trabalho que teremos inicialmente para modificar tudo que temos, mais faremos com prazo extendido para facilitar.


    Só para ficar Claro,

    Nossos sistemas terão apenas permissão "DML".
    Então a estrategia seria:

    1. Criar schemas para cada aplicação;
    2. Duvidas na estrutura das roles:
      2.1 Criar uma role com permissão DML por aplicação?
      2.2 Criar uma role com permissão DML apenas e associar todos os usuarios a ele?
            Neste caso aqui, acho que não funciona pq as roles estão associado aos schemas, logo todo usuario terá acesso a todos os schemas.

    3. Associar as roles aos Schemas;
    4. Criar um login para cada Aplicação
    2. Criar um usuario para cada Aplicação
    3. Associar os usuarios as roles? seguindo o padrão 2.1

    4. Tenho uma tabela qu é de bem comum de todas as aplicações, que é a de "usuario" do sistema SGI(sistema de gerenciamento interno).

    O sistema da extranet altera senha/ ou email deste tabela, então o usuario "uExtranet" tenho que da permissão direta a tabela usuario que esta em outro schema? 
    Tenho que relaciona este usuario ao schema "sgi" e lá posso apenas deixar ele manipular o UPDATE nos campos especificos?
    Tenho que relacionar ele a roles do SGI e da permissão apenas de UPDATE nos campos especificos?

    Qual seria o caminho??

    Não podemos esquecer das futura manutenções.



    OBSERVAÇAO:
    1. Criei a roles
        Apliquei duas perimissões, os schemas "db_datawriter" e "db_datareader";
    2. Associei o usuario a roles.
    3. Criei o schema
    4. Associei a roles ao Schema.
    OBS: Neste momento, não consegui apenas associar,pq tinha que dar as permissões de "SELECT, INSERT, UPDATE" etc . como apenas ADD, não ficava.

    ENtão as roles são grupos?? crio as roles, associo aos usuarios;
    E no momento de associar as roles ao schema q dou as permissões??



    Forte abraço e  obrigado!

      






    Att, Luiz Anderson - Programador DOTNET, Administrador SQL SERVER 2005
    quinta-feira, 30 de julho de 2009 14:24
  • Anderson imagino o seguinte cenário:

    1 - Criar um schema para cada aplicação
      EX: cpd, aluno, Extranet, notes, Curriculo, iol >>>> na minha opnião não precisa deixar um tamanho fixo o nome do schema e sim um valor que realmente   expresse sua aplicação

    2 - Criar um login e usuário para cada aplicação
      EX: SI$CPD, SI$ALUNO, SI$EXTRANET........ obs: lembre de colocar o default schema correto para cada usuário ex:> Para o usuário SI$CPD o schema será o cpd

    3 - Como você só terá um usuário por aplicação você poderia já dar as permissões no schema diretamente para o usuário, mas já pensando no futuro, mesmo por enquanto tendo apenas um usuário por aplicação crie um ROLE para cada aplicação, assim no futuro se surgir novos usuários só inclui-los na role.
      EX: RO_CPD, RO_ALUNO, RO_EXTRANET........ No onwer de cada role coloque um login com poderes Sysadmin, pode usar o mesmo para todas as roles a mesma coisa para os schemas.

    4 - Dar as permissões DML(INSERT, UPDATE, DELETE, SELECT, EXECUTE E ALTER) NO SCHEMA CORRESPONDETE A ROLE CRIADA.
      EX: Na role RO_CPD você seleciona em securables o schema SI$CPD e da grant nas permissões acima, da mesma forma para as outras roles.

    5 - Em cada ROLE adiciona o usuário criado para aplicação do schema associado a role.
      ex: Na role RO_CPD em Role Members adicione somente o SI$CPD e assim por diante paras as outras roles.

    Para solucionar o problema da tabela corporativa de usuários, você pode criar um role por ex chamada CORP_SEL com permissão apenas de SELECT na tabela de usuários e não no schema inteiro, apenas nesta tabela específica. Adicione em members desta role todas as outras roles das aplicações que precisarem realizar select nesta tabela, assim além das permissões apenas no schema associado as roles também terão permissão de select nesta tabela.

    Cria uma outra role CORP_UPD com permissão de update na tabela de usuários e adicione no members desta role, todas as roles que devem ter permissão de update nesta tabela.

    acho que desta forma se torna possível realizar manutenções futuras sem impacto no schema.

    esclareceu algo, ou ainda tem dúvidas? 
    DBA SQL Server MCTS - SQL Server 2005 | ITIL Foundation V2 http://www.bydocs.com
    • Sugerido como Resposta Fernanda Simões terça-feira, 4 de agosto de 2009 14:12
    • Marcado como Resposta anderson s. dias sexta-feira, 25 de setembro de 2009 12:32
    quinta-feira, 30 de julho de 2009 17:32
  • Anderson, implantou os schema? encontrou a solução?
    DBA SQL Server MCTS - SQL Server 2005 | ITIL Foundation V2 http://www.bydocs.com
    quarta-feira, 5 de agosto de 2009 20:48
  • Olá Cleyton,

    pesso mil descupas pela enorme demora da resposta... Aqui na empresa sou Programador web como assumi o banco de dados. Ai já viu, sistema deu ____, final da 2º unidade ai preferencia etc.

    Sim, fiz os testes e tenho gostado dos resultados.
    Estou concluindo a modelagem de um sistema para já implantar esta politica e ter como analisar melhor na pratica.
    Já passei para meu Gestor e outrocolega aqui Programador que a forma facil de tratar com o DB vai se estreitar...

    Irei estes dias concluir os testes e volto a postar as novidades.


    Forte Abraço
    Att, Luiz Anderson - Programador DOTNET, Administrador SQL SERVER 2005
    sexta-feira, 25 de setembro de 2009 12:31
  • OK Anderson, que bom que foi util. Boa sorte.
    ITILF | MCP | MCTS | MCITP SQL Server 2005 & 2008. http://www.bydocs.com
    sexta-feira, 25 de setembro de 2009 13:30