Pt individual - ADS - Telecine Mozer

Prévia do material em texto

SISTEMA DE ENSINO PRESENCIAL CONECTADO
CURSO SUPERIOR DE TECNOLOGIA EM
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
WANDERLEY NUNES CRISTO
DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO II
Produção Textual Interdisciplinar – Portfolio
Trabalho apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas à Universidade Norte do Paraná - UNOPAR, para as disciplinas Banco de Dados II, Análise Orientada a Objetos II, Programação Orientada a Objetos, Programação para Web I e Seminários IV.
Prof.: Roberto Y. Nishimura, Anderson Emídio M.Gonçalves, Marcio Roberto Chiaveli e Prof.ª Veronice de Freitas.
Tutor eletrônico: Jose Henrique Lopes Oliveira Bento
Tutor de sala: Rosinaldo Leão dos Santos
Breves
2014
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................... 3
2 OBJETIVO ........................................................................................................... 4
3 SEGURANÇA NO DESENVOLVIMENTO DE APLICAÇÕES WEB..................... 5
3.1 VULNERABILIDADES COMUNS ..................................................................... 6
3.2 UTILIZAÇÕES DE FIREWALLS E PROTOCOLO HTTPS. .............................. 7
3.2.1 FIREWALLS .................................................................................................. 7
3.2.2 HTTPS: ......................................................................................................... 8
4 DIAGRAMA DE ATIVIDADE (UML) ..................................................................... 9
4.1 CONCEITOS USADOS NOS DIAGRAMAS DE ATIVIDADES ......................... 9
4.2 ESTADO DE ATIVIDADE E ESTADO DE AÇÃO ........................................... 10
4.3 EXEMPLO DE DIAGRAMA DE ATIVIDADE .................................................. 11
5 NORMALIZAÇÃO DO DIAGRAMA ENTIDADE RELACIONAMENTO (MRN) ... 12
5.1 MODELO ENTIDADE RELACIONAMENTO (MER) ....................................... 12
5.2 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER) .................................... 12
5.3 NORMALIZAÇÃO ........................................................................................... 13
5.4 DER NORMALIZADO ..................................................................................... 15
6 CONCLUSÃO .................................................................................................... 16
REFERÊNCIAS ...................................................................................................... 17
1 INTRODUÇÃO
Hoje os serviços disponibilizados para uma infinidade de situações estão mudando cada vez mais para a plataforma WEB, isso ocorre devido a facilidade que essa plataforma proporciona. Porém, nem sempre, as aplicações desenvolvida para essa plataforma atendem os requisitos básicos de segurança da informação, confiabilidade da informação e disponibilidade da informação. Nesse trabalho, além de abordarmos esse pontos, também falaremos de diagramas de atividade e normalização de um Diagrama de Entidade Relacionamento.
2 OBJETIVO
Este trabalho tem por objetivo levar o aluno a conhecer os problemas básicos que ocorrem no desenvolvimento de aplicações WEB, tendo como foco a segurança no desenvolvimento de aplicações WEB. Os conceitos básicos de um Diagrama de Atividade e suas características e a Normalização de dados no Diagrama Entidade Relacionamento.
3  Segurança no desenvolvimento de Aplicações Web
                            Atualmente as vulnerabilidades nas aplicações web são o maior vetor para os ataques contra a segurança de TI. Os artigos no noticiário acerca dos ataques que comprometem os dados confidencias frequentemente mencionam o método usado sendo “cross-site scripting”, “SQL injection” e “erros de configurações de websites”. Muitas vezes as vulnerabilidades deste tipo estão fora da experiência tradicional dos administradores de segurança de TI. Esta relativa obscuridade das vulnerabilidades dos aplicações web faz deles alvos atrativos para atacantes. Como muitas organizações têm descoberto, esses ataques evadirão as defesas tradicionais das redes empresariais, e novas defesas são necessárias. As vulnerabilidades das aplicações web em geral tem origem em configurações com falhas ou em erros de programação nas linguagens usadas para aplicações web (Java, .NET, PHP, Python, Perl, Ruby, etc.). Estas vulnerabilidades podem ser complexas e podem se manifestar em muitas situações diferentes.
                            A segurança das aplicações, principalmente aquelas conectadas a uma rede aberta é perigosa como é a Internet. Essa complexidade advém do fato que as aplicações web são agrupamentos bastante heterogêneos de plataformas, bancos dedados, servidores de aplicação, etc. Uma aplicação típica, geralmente, está distribuída em vários servidores, rodando diversos aplicativos e para funcionar na velocidade adequada, a aplicação precisa que as interfaces entre os diversos sistemas sejam construídas com a premissa que os dados passados através da mesma são confiáveis e não hostis. Não há tempo hábil para duplas verificações nas aplicações e a necessidade de haver “confiança” entre os diversos subsistemas e é disso que os hackers e outros ciber criminosos se aproveitam. Para o sistema aplicativo, frequentemente desenvolvido in house ou por terceiros, especificamente para a empresa, não existem patches de segurança. Segundo o Gartner, 75% dos ataques são concentrados nos aplicativos específicos de cada empresa, pois os atacantes sabem das suas fragilidades.
3.1   Vulnerabilidades comuns
Nestes sistemas complexos, a segurança dos produtos disponíveis no mercado é assegurada pelos fabricantes, que fornecem periodicamente patches que os atualizam.
Os ataques que hoje conhecemos são baseados em vulnerabilidades típicas de aplicações web complexas. Mesmo os sistemas operacionais que são mantidos por grandes empresas, empregando milhares de profissionais, têm vulnerabilidades que são periodicamente descobertas por hackers e só se transformam em patches depois que os hackers já atacaram algumas vezes, que o problema foi comunicado ao fabricante e devidamente corrigido.
A Internet agregou outros componentes de risco, sendo muito importante o “efeito comunidade” em que os hackers e outros criminosos se julgam fazendo parte de uma “comunidade” e obrigados a compartilhar rapidamente suas descobertas. Isto significa que qualquer vulnerabilidade descoberta nas suas aplicações será rapidamente divulgada, com as ferramentas necessárias para atacá-la, e outros hackers e cibe criminosos aproveitarão as vulnerabilidades da sua aplicação. Os ataques podem causar uma série de problemas, entre os quais se podem citar:
Perdas Financeiras;
Transações Fraudulentas;
Acesso não autorizados a dados, inclusive confidenciais;
Roubo ou modificação de Dados;
Roubo de Informações de Clientes;
Interrupção do Serviço;ü  Perda da confiança e lealdade dos clientes;
Dano à imagem da marca.
 Os tipos mais comuns de ataques são:
Cross-Site Scripting
SQL Injection
Command Injection
Cookie/Session Poisoning
Parameter/Form Tampering
Buffer Overflow
Directory Traversal/Forceful Browsing
Cryptographic Interception
Cookie Snooping;
Authentication Hijacking
3.2   Utilizações de firewalls e protocolo HTTPS.
3.2.1   FIREWALLS
A maioria dos firewalls de rede, por se concentrar nas camadas mais baixas, não protege as aplicações da maior parte desses ataques, protege sim o acesso aos recursos de rede.
Uma nova geração de appliances está surgindo para resolver este e outros problemas, o Aplicativo Firewalls.
Fazem parte de um novo conceito, que é a defesa na camada de aplicação. Defesa das aplicações dos clientes, não padronizadas, heterogêneas, distribuídasem vários sistemas operacionais, usando diversos servidores de aplicação e de bancos de dados.
Surgiram só agora, por duas razões, primeiro a necessidade de combater ataques cada vez mais inteligentes e segundo a disponibilidade da tecnologia necessária para a criação desses appliances que necessitam monstruosa capacidade de computação.
O Gartner Group identificou como uma tendência à transformação do firewall comuns em commodities, em que a principal diferença entre os diversos appliances é o preço, pois as funcionalidades e a tecnologia são bastante similares, e o surgimento de novos líderes no Gartner Quadrante Mágico dos Firewall.
3.2.2   HTTPS:
Hypertext Transfer Protocol Secure, é uma implementação do protocolo HTTP's sobre uma camada adicional de segurança que utiliza o protocolo SSL/TLS. Essa camada adicional permite que os dados sejam transmitidos através de uma conexão criptografias e que se verifique a autenticidade do servidor e do cliente através de certificados digitais. A porta TCP usada por norma para o protocolo HTTPS é a 443.
O protocolo HTTPS é utilizado, em regra, quando se deseja evitar que a informação transmitida entre o cliente e o servidor seja visualizada por terceiros, como, por exemplo, no caso de compras on-line. A existência na barra de tarefas de um cadeado (que pode ficar do lado esquerdo ou direito, dependendo do navegador utilizado) demonstra a certificação de página segura (SSL). A existência desse certificado indica o uso do protocolo HTTPS e que a comunicação entre o browser e o servidor se dará de forma segura. Para verificar a identidade do servidor é necessário abrir esse certificado com um duplo clique no cadeado para exibição do certificado.
Nas URL's dos Sites o início ficaria 'https://'. Consulte a ajuda do seu navegador para mais informações de como ele avisa sobre sites seguros. Um exemplo de conexão via HTTPS são os próprios sites da Wikipédia, em que é possível acessar e editar o conteúdo dos sites através de uma conexão segura. Através da URL é possível editar a Wikipédia em língua Portuguesa.
Conexões HTTPS são frequentemente usadas para transações de pagamentos na World Wilde Web e para transações sensíveis em sistemas de informação corporativos. Porém, o HTTPS não deve ser confundido com o menos utilizado protocolo "Secure HTTP" (S-HTTP), especificado na RFC 2660.
4  Diagrama de Atividade (UML)
Um diagrama de atividade é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra e serão empregados para fazer a modelagem de aspectos dinâmicos do sistema. Na maior parte, isso envolve a modelagem das etapas sequenciais em um processo computacional; Enquanto os diagramas de interação dão ênfase ao fluxo de controle de um objeto para outro, os diagramas de atividades dão ênfase ao fluxo de controle de uma atividade para outra; Uma atividade é uma execução não atômica em andamento em uma máquina de estados e acabam resultando em alguma ação, formada pelas computações atômicas executáveis que resultam em uma mudança de estado do sistema ou o retorno de um valor.
O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem Unificada (UML), e representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Comumente isso envolve a modelagem das etapas sequenciais em um processo computacional.
Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.
4.1   Conceitos Usados nos Diagramas de Atividades
Atividades: Comportamento a ser realizado.
Sub-atividade: Execução de uma sequência não atômica de atividades.
Transição: Fluxo de uma atividade para outra.
Ação: Transformação.
Decisão: Dependendo de uma condição, mostra as diferentes transições.
Raia: Diferenciação de unidades organizacionais.
Bifurcação (Fork): Separa uma transição em várias transições executadas ao mesmo tempo.
Sincronização (Join): Concatenação de transições vindas do Fork.
Objeto: O objeto da atividade.
Envio de sinal: Transição pra um meio externo, por exemplo, um hardware.
Recepção de sinal: Recepção do envio.
Região: Agrupamento de uma ou mais atividades.
Exceção: Atividades que ocorrerem em decorrência de uma exceção.
                            Os diagramas de atividade costumam conter:
Estado de atividade e estado de ação.
Transições
Objetos
4.2   Estado de atividade e estado de ação
                            No fluxo de controle modelado por um diagrama de atividade é onde as atividades acontecem. É possível calcular uma expressão que defina um conjunto de valor de um atributo ou que retorne algum valor. Alternativamente, você poderá chamar uma operação num objeto, enviar um sinal a um objeto ou até criar ou destruir um objeto. Estas computações atômicas executáveis são chamados estado de ação.
Os estados de ação não podem ser decompostos. Além disso, os estados de ação são atômicos, significando que os eventos poderão ocorrer, mas o trabalho de estado de ação não é interrompido. O trabalho de estado de ação é geralmente considerado como ocupando um tempo de execução insignificante.
Em contraste, os estados de atividade podem ser decompostos, suas atividades sendo representadas por outros diagramas de atividades. Além disso, os estados de atividade são não-atômicos, significando que poderão ser interrompidos e, em geral, são considerados como tomando algum tempo para serem completados.
4.3   Exemplo de Diagrama de Atividade
5  Normalização do Diagrama Entidade Relacionamento (MRN)
5.1   Modelo entidade relacionamento (MER)
Em engenharia de software, um modelo entidade relacionamento (modelo ER) é um modelo de dados para descrever os dados ou aspectos de informação de um domínio de negócio ou seus requerimentos de processo, de uma maneira abstrata que em última análise se presta a ser implementada em um banco de dados, como um banco de dados relacional. Os principais componentes dos modelos ER são entidades (coisas) e os relacionamentos que podem existir entre eles, e bancos de dados.
Um modelo entidade relacionamento é uma maneira sistemática de descrever e definir um processo de negócio. O processo é modelado como componentes (entidades) que são ligadas umas às outras por relacionamentos que expressam as dependências e exigências entre elas, como: um edifício pode ser dividido em zero ou mais apartamentos, mas um apartamento pode estar localizado em apenas um edifício. Entidades podem ter várias propriedades (atributos) que os caracterizam. Diagramas criados para representar graficamente essas entidades, atributos e relacionamentos são chamados de diagramas entidade relacionamento.
Um modelo ER é normalmente implementado como um banco de dados. Nos casos de um banco de dados relacional, que armazena dados em tabelas, as próprias tabelas representam as entidades. Alguns campos de dados nestas tabelas apontam para índices em outras tabelas. Tais ponteiros representam relacionamentos.
5.2   Diagrama Entidade-Relacionamento (DER)
O Diagrama Entidade-Relacionamento descreve toda estrutura lógica do banco de dados. É possível construí-lo a partir de um MER, identificando assim a partir de um conceito do mundo real como os dados serão armazenados de fato.
O DER tem como ênfase os dados e os relacionamentos. Sua representação utiliza os símbolos:
    Retângulos - representam as entidades;
    Elipses - representam os atributos;
    Losangos - representam os relacionamentos entre as entidades;
    Linhas - unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos conjuntos de relacionamentos;
    Elipses duplas - atributos multivalorados.
Na construção de um projeto de banco de dados é necessário saber quais são os objetos e os relacionamentos para elaborar o DER, ouseja, descobrir quais os atributos que compõem as tabelas (objetos).
5.3   Normalização
A utilização do MER nos proporciona a criação de um DER (Diagrama de Entidades e Relacionamento). Os DER fazem uma representação de parte de um mundo real onde são feitas representações estruturadas e conceituais do que o ser humano pode fazer nessa parcela do mundo real.
A princípio, Peter Chen propôs como notação desses diagramas os retângulos como sendo as entidades, os losangos como sendo os relacionamentos entre as entidades, os círculos como sendo os atributos das entidades e linhas de conexão para mostrar a cardinalidade entre uma entidade e outra.
Ao aplicar esse sistema de Relacionamento, existem uma série de passos para fazer com que os dados tornem-se menos redundantes e menos inconsistentes. Tais passos são chamados de Normalização de dados. A primeira forma normal foi definida por Edgar F. Codd em 1970. Essa norma tinha como definição permitir que os dados fossem questionados e manipulados usando uma "sub-linguagem de dados universal" atrelada à lógica de primeira ordem. Nem sempre essa normalização é eficiente, dependendo da separação entre o projeto lógico da base de dados e a implementação física do banco de dados.
Para normalização é feito um trabalho sobre as restrições que indicam relações individuais, isto é, as restrições relacionais. O propósito destas restrições é descrever o universo relacional, ou seja, o conjunto de todas as relações que são permitidas para serem associadas com certos nomes de relação. Dentre essas restrições relacionais, a mais importante é a Chave, a qual vai relacionar um registro com um ou mais valores de índice.
Existem hoje diversas normas formais, cada uma gerando aprimoramentos em relação à norma anterior. Abaixo as normas e definições:
Primeira Norma Formal: Uma tabela está na 1FN, se e somente se, não possuir atributos multivalor.
Segunda Norma Formal: Uma relação está na 2FN se, e somente se, estiver na 1FN e cada atributo não-chave for dependente da chave primária inteira, isto é, cada atributo não-chave não poderá ser dependente de apenas parte da chave.
Terceira Norma Formal: Uma relação R está na 3FN, se estiver na 2FN e cada atributo não-chave de R não possuir dependência transitiva, para cada chave candidata de R.
Quarta Norma Formal: Uma tabela está na 4FN, se e somente se, estiver na 3FN e não existirem dependências multivaloradas.
5.4   DER Normalizado
6  CONCLUSÃO
Nos dias atuais é impensável desenvolver uma aplicação sendo ela para qualquer plataforma sem pensar em um item essencial chamado segurança. Esse trabalho de pesquisa trouxe conhecimentos que serão extremamente uteis para quem pretende trabalhar com esse tipo de desenvolvimento. A segurança das aplicações voltadas para a Web é um dos requisitos básicos para termos uma aplicação funcionado de forma adequada, disponibilizado para os clientes toda a segurança que sempre queremos ao utilizar qualquer serviço.
Estuda um pouco mais sobre Diagrama de atividade melhorou bastante o entendimento sobre o mesmo, quando devemos implementar o diagrama, e os benefícios de sua utilização dentro do projeto de desenvolvimento.
A normalização dentro de um projeto é fundamental para um correto funcionamento da aplicação e principalmente do banco de dados. Pesquisar um pouco mais sobre a Normalização no Diagrama Entidade Relacionamento (DER) só veio a enriquecer ainda mais o conhecimento adquirido durante o semestre.
REFERÊNCIAS
ANHANGUERA NITERÓI, Banco de Dados I. Disponível em: (https://sites.google.com/site/uniplibancodedados1/aulas/aula-4---modelo-entidade-e-relacionamentos) Acesso em: 19 de outubro de 2014. 
DEVMEDIA.COM.BR, Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER). Disponível em: (http://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332) Acesso em: 19 de outubro de 2014.
GUILHERMEPONTES.ETI.BR, Revisão. Disponível em: (http://www.guilhermepontes.eti.br/sgbd/revisao.pdf) Acesso em: 19 de outubro de 2014.
MACORATTI.NET, .NET - Implementando Soluções OOP II. Disponível em: (http://www.macoratti.net/11/09/net_ioop2.htm) Acesso em: 19 de outubro de 2014.
OWASP.ORG, As 10 vulnerabilidades de segurança mais críticas em aplicações WEB. Disponível em: (https://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf) Acesso em: 19 de outubro de 2014.
SITEBLINDADO.COM, Segurança Para aplicações Web. Disponível em: (http://www.siteblindado.com/pt/pags/view/files/WhitePaper+QualysGuard+Vulnerability+Web+Applications.pdf) Acesso em: 19 de outubro de 2014.
WIKIPEDIA, Diagrama de atividade. Disponível em: (http://pt.wikipedia.org/wiki/Diagrama_de_atividade) Acesso em: 19 de outubro de 2014.
WIKIPEDIA, Modelo entidade relacionamento. Disponível em: (http://pt.wikipedia.org/wiki/Modelo_entidade_relacionamento) Acesso em: 19 de outubro de 2014.