Atividade-Interdisciplinar-6º-Semestre-Individual.docx

8/10/2019 Atividade-Interdisciplinar-6-Semestre-Individual.docx

1/34

Juazeiro - BA2014

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

SISTEMA DE ENSINO PRESENCIAL CONECTADOTECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS

ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL


2/34

Juazeiro - BA2014

ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL

Trabalho apresentado ao Curso de Tecnologia emAnlise e Desenvolvimento de Sistemas da UniversidadeNorte do ParanUNOPAR

Professores: Anderson GonalvesAdriane LoperMerris MozerVeronice de Freitas

XXXXXXXXXXXXXXXXXXXXXXXXXXXXX


3/34


4/34

SUMRIO

1

INTRODUO ..................................................................................................... 3

2 OBJETIVO ........................................................................................................... 4

3 RECURSOS UTILIZADOS EM DISPOSITIVES MVEIS ................................... 5

3.1 PERSISTNCIA EM APLICATIVOS PARA DISPOSITIVOS MVEIS COM

J2ME ........................................................................................................................... 5

3.1.1 J2ME e perfil MIDP ....................................................................................... 5

3.1.2 RMS .............................................................................................................. 6

3.1.3

Classe RecordStore ...................................................................................... 7

3.2 THREAD .............................................................................................................. 7

3.3 SINCRONIA DE PROCESSOS ............................................................................ 8

3.3.1 Excluso Mtua Com Espera Ativa ............................................................... 9

3.3.2 Desativando as Interrupes ........................................................................ 9

3.3.3 Variveis de Bloqueio ................................................................................... 9

3.3.4 Alternncia Estrita ......................................................................................... 9

3.3.5

Soluo de Peterson ................................................................................... 10

3.3.6 Deadlock ..................................................................................................... 10

3.3.7 Starvation .................................................................................................... 10

3.4 USABILIDADE DE INTERFACES PARA DISPOSITIVOS MVEIS .................. 10

3.4.1 Recomendaes Crticas Para o Projeto de Interfaces Mobile ................... 11

3.4.1.1 Reduzir clicks .............................................................................................. 11

3.4.1.2 Reduzir funcionalidades .............................................................................. 12

3.4.1.3

Reduzir contedo ........................................................................................ 12

3.4.1.4 Dar escolhas ao usurio ............................................................................. 12

3.4.2 Prticas Importantes Que Herdamos da Usabilidade Convencional

....................................................................................................................................12

3.4.2.1 Integridade esttica ..................................................................................... 12

3.4.2.2 Consistncia ............................................................................................... 12

3.4.2.3 Metforas .................................................................................................... 13

3.4.2.4 Contexto do usurio .................................................................................... 13

3.4.2.5 Modelo mental ............................................................................................ 13

3.4.2.6 Navegao .................................................................................................. 13


5/34

3.4.2.7 Interao e feedback ................................................................................... 13

3.4.2.8 Aparncia e design ..................................................................................... 13

3.4.2.9 Visualizao de informaes ...................................................................... 13

3.5

JAVA DB E DISPOSITIVOS MVEIS ................................................................ 14

4 GESTO E SEGURANA NO SISTEMA DE INFORMAO .......................... 17

4.1 ENGENHARIA SOCIAL ..................................................................................... 17

4.1.1 Evitando a Engenharia Social ..................................................................... 19

4.2 VULNERABILIDADE .......................................................................................... 20

4.2.1 Anlise de Vulnerabilidades ........................................................................ 20

4.2.2 Aorigem das Vulnerabilidades .................................................................... 20

4.2.3 Principais Objetivos da Anlise de Vulnerabilidades................................... 21

4.3 AMEAAS, ATAQUES E VULNERABILIDADES ............................................... 21

4.3.1 Alguns Exemplos de Ameaas e Vulnerabilidades ..................................... 22

4.4 MEDIDAS DE SEGURANA E POLTICA DE SEGURANA ........................... 25

4.4.1 As causas da Insegurana .......................................................................... 26

4.5 AUDITORIA DE SISTEMAS DE INFORMAO ............................................... 26

4.5.1 O Auditor de Sistemas ................................................................................ 28

5

CONCLUSO .................................................................................................... 30

REFERNCIAS ......................................................................................................... 31


6/34

3

1 INTRODUO

Neste trabalho ser abordada toda a matria do 6 Semestre, dentro

deste contexto ser apresentado vrios recursos utilizados em dispositivos mveis,

como sincronia de processos, a persistncia dos dados e threads.

No contexto dos sistemas mveis ser mostrado usabilidade de

interfaces para dispositivos mveis, e podendo como isso trazer benefcios para os

usurios, como a facilidade de uso, melhorando assim a forma dos usurios

interagirem com os dispositivos.

Falaremos sobre a gesto e segurana no sistema de informao,

onde sero descritos alguns critrios como vulnerabilidades, ameaas, ataques,engenharia social, medidas de segurana e auditoria.


7/34

4

2 OBJETIVO

Objetivo desta produo textual aprofundar-se nos contedos

estudados durante o semestre, aperfeioando as tcnicas e conceitos vistos no

decorrer do semestre, obtendo experincia para confeco do Trabalho de

Concluso de Curso.


8/34

5

3 RECURSOS UTILIZADOS EM DISPOSITIVES MVEIS

3.1 PERSISTNCIA EM APLICATIVOS PARA DISPOSITIVOS MVEIS COM J2ME

A capacidade de persistir dados ou armazenar informaes sem

dvida um dos recursos mais importantes em qualquer linguagem de programao.

Armazenar dados para uma posterior recuperao uma constante na maioria dos

ambientes computacionais, seja para persistncia simples de parmetros de

configuraes do sistema ou persistncia de informaes digitadas pelo usurio para

alimentar banco de dados.

A respeito da persistncia em ambientes computacionais, ocomplicador quando esse mesmo ambiente tem recursos de armazenamento

restrito e uma arquitetura de hardware e software bem diferente da encontrada em

desktops ou grandes servidores, como o caso dos dispositivos mveis. Essas

diferenas podem ser observadas tanto do ponto de vista do usurio (ergonomia de

hardware e software), quanto do ponto de vista do desenvolvedor (ferramentas de

software, APIs e recursos). Os telefones celulares conseguiram alcanar uma

popularidade quase to grande quanto a observada na utilizao de computadores

pessoais a partir da dcada de 80. Mas, assim como todos os dispositivos mveis,

eles tambm trazem consigo algumas dificuldades, problemas relacionados

ergonomia do teclado, interface visual simples limitada e a dependncia de

baterias que requerem recarga constante.

3.1.1 J2ME e perfil MIDP

O Java 2 Micro Edition (J2ME) foi desenvolvido para contemplar

toda a diversidade computacional existente nos dispositivos mveis. A tecnologia

J2ME conseguiu abstrair conceitos e tcnicas para homogeneizar o desenvolvimento

em dispositivos mveis de forma completamente transparente. O perfil de

informao de dispositivos mveis, conhecido como MIDP (Mobile Information

Device Profile) surgiu como soluo para diferenciar dispositivos que apesar de

possurem caractersticas semelhantes, ainda assim so tecnologicamentediferentes. O perfil MIDP contempla os aparelhos celulares e o responsvel pela


9/34

6

definio das APIs necessrias para a persistncia de dados.

3.1.2 RMS

O conjunto de classes responsveis por armazenar e recuperar

dados conhecido como Record Management System (RMS) ou sistema de

gerenciamento de registros. O RMS permite manter os dados persistentes entre

vrias chamadas de um MIDlet (aplicao baseada no MIDP). Segundo a

especificao MIDP, deve haver, disponvel no dispositivo, pelo menos 8 kbytes de

memria no-voltil (ROM) para que os aplicativos persistam dados. Exemplos de

memria no-voltil seriam ROM, flash e etc. Em teoria, todo o espao livre namemria ROM, ou flash de um dispositivo mvel, estaria disponvel aos aplicativos

para persistirem seus dados.

A unidade bsica de dados mantida pelo RMS conhecida como

Record Store ou repositrio de registro (RR). Um RR pode ser comparado a uma

tabela ou entidade no modelo relacional e identificado por um nome de at 32

caracteres. Cada registro composto por um identificador nico e um array de bytes,

onde os dados do registro sero armazenados. Um RR mantm em sua estrutura

um conjunto de registros que podem ter tamanhos variveis.

Um MIDlet um aplicativo executado em um dispositivo mvel. Para

isso, ele precisa ser empacotado em um arquivo Java (JAR). Um MIDlet pode, ainda,

ser empacotado junto com outros MIDlets em um mesmo arquivo JAR, formando um

conjunto. Tanto um MIDlet quanto um conjunto de MIDlets, formam uma aplicao

J2ME nica e completa. Cada conjunto de MIDlets ou um MIDlet, pode criar e

manter diversos RRs, podendo, inclusive, compartilh-los entre si, com o detalhe de

que os nomes atribudos aos RRs precisam ser nicos. A verso 1.0 do MIDP no

permitia o compartilhamento de RRs entre MIDlets empacotados em diferentes

arquivos JAR. A verso 2.0 do MIDP corrigiu essa limitao, permitindo assim o

compartilhamento de um RR por todas os MIDlets instalados no dispositivo.

As APIs do RMS no fornecem recurso para travamento de

registros. A implementao de um RR garante que a operao de persistncia ser

realizada de forma indivisvel e sncrona evitando eventuais inconsistncias no caso

de acessos mltiplos. Se for necessrio que um MIDlet utilize mltiplas threads para

acessar um RR, necessrio toda uma ateno para manter a consistncia dos


10/34

7

dados. Tambm, responsabilidade da implementao no dispositivo fazer todo o

possvel para garantir a integridade e a consistncia dos RRs durante operaes

normais ao seu uso como reinicializao, troca de baterias e etc.

Durante a desinstalao de um MIDlet do dispositivo, os armazns

de dados pertencentes a ele so removidos automaticamente.

3.1.3 Classe RecordStore

Qualquer operao de insero, atualizao e excluso de registros

em um RR provocam a atualizao automtica do seu nmero de verso e da data

em que ocorreu a mudana. O nmero da verso de um RR pode servir comoreferencial, por exemplo, para algoritmos de replicao. uma maneira interessante

de detectar quantas vezes um RR foi modificado. Esses dois valores, o nmero da

verso e a data da atualizao, podem ser recuperados atravs do uso dos mtodos

getVersion() e getLastModified() respectivamente.

3.2 THREAD

Para programas "normais" (single thread), tem um nico ponto de

execuo dentro do programa num momento particular, um thread semelhante:

tem um incio, uma sequncia e um fim, como um programa "normal". Tem um nico

ponto de execuo no certo momento dentro de um thread.

O thread no um programa, mas executa dentro de um programa

Definio: thread um fluxo nico de controle sequencial dentro de

um programa.

A coisa fica mais interessante quando temos mais de um thread no

mesmo programa.

O browser um exemplo de uma aplicao multithreaded, onde

vrias coisas podem ocorrer ao mesmo tempo:

Scroll;

Download de um applet;

Download de uma imagem;

Tocar uma animao;

Tocar um som;


11/34

8

Imprimir uma pgina em background;

Download de uma nova pgina;

Olhar 3applets de ordenao trabalhando.

Um thread parece ser um processo, mas compartilha o mesmo

"espao de endereamento", sendo muito rpido chavear a execuo entre threads

mas no entre processos.

O thread recebe alguns recursos prprios durante a execuo:

Uma pilha de execuo para poder chamar mtodos, passar

parmetros, alocar variveis locais;

Um "ProgramCounter";

Chamamos isso o "contexto de execuo do thread";

Alguns autores chamam thread de "contexto de execuo".

3.3 SINCRONIA DE PROCESSOS

A sincronia de processos permite gerenciar o acesso concorrente a

recursos do sistema operacional de forma controlada por parte dos processos, de

maneira que um recurso no seja modificado em simultneo, ou que os processosno fiquem em espera que o recurso seja libertado.

Os processos (aplicativos ou programas) de um computador

compartilham determinados recursos da chamada regio crtica, que so as

variveis globais, as instrues de E/S, algum banco de dados, etc. Neste

compartilhamento podem ocorrer erros.

Exemplo:

A Unopar est fazendo suas matrculas apenas pela internet, o comum nmero de vagas limitadas igual a 10, dois usurios esto fazendo a matrcula

no mesmo momento, finalizam a matrcula. A operao que o programa usa da

regio crtica:matrcula finalizada -1.

Se os dois usurios fazem a operao ao mesmo tempo, quando a

matricula for finalizada subtrai-se 1 vaga:

Matrcula finalizada -1 (10-1)=9

Matrcula finalizada -1 (10-1)=9

Quando um terceiro usurio for fazer uma matrcula, o nmero de

vagas ser expresso como 9, sendo que na verdade deveria ser 8. Isto causar
http://pt.wikipedia.org/wiki/Regi%C3%A3o_cr%C3%ADticahttp://pt.wikipedia.org/wiki/Regi%C3%A3o_cr%C3%ADtica


12/34

9

instabilidade e poder comprometer todo o sistema. A soluo para este tipo de caso

a certeza de excluso mtua, isto , apenas um processo pode acessar a regio

crtica por vez; Os mecanismos que implementam a excluso mtua utilizam um

protocolo de acesso regio crtica.Toda vez que um processo for executar sua

regio crtica, ele obrigado a passar por um controle de entrada e outro de sada.

3.3.1 Excluso Mtua Com Espera Ativa

Apenas um processo acessa a regio crtica de cada vez. Espera

ativa faz testes continuos em uma varivel, at que ela seja alterada, causando

assim um grande disperdicio de CPU. Abaixo temos solues para problemas comoo mostrado acima.

3.3.2 Desativando as Interrupes

A forma mais simples de garantir a excluso mtua fazer com que

o processo desabilite as interrupes ao entrar na regio crtica, e antes de sair

ashabilite novamente. Com isso a CPU no far um chaveamento no momento em

que o processo estiver na regio crtica, pois o chaveamento vem de uma

interrupo atravs de um relgio.

3.3.3 Variveis de Bloqueio

Quando uma vriavel "lock" estiver como 0, significa que a regio

crtica esta livre, e 1 esta ocupada. Assim, antes de entrar cada processo testa o

valor da varivel "lock", se for 0, coloca como 1 e entra na regio crtica, aps saircoloca o valor 0, se o valor j for 1, aguarda at ser 0.

3.3.4 Alternncia Estrita

Neste metodo, criada uma varivel "turn", com valor inicial 0, a

imagem abaixo mostra dois processos 'a' e 'b' utilizando este metodo.
http://pt.wikipedia.org/wiki/Exclus%C3%A3o_m%C3%BAtuahttp://pt.wikipedia.org/wiki/Regi%C3%A3o_cr%C3%ADticahttp://pt.wikipedia.org/wiki/Regi%C3%A3o_cr%C3%ADticahttp://pt.wikipedia.org/wiki/Regi%C3%A3o_cr%C3%ADticahttp://pt.wikipedia.org/wiki/Regi%C3%A3o_cr%C3%ADticahttp://pt.wikipedia.org/wiki/Exclus%C3%A3o_m%C3%BAtua


13/34

10

Fonte:http://pt.wikipedia.org/wiki/Sincronia_de_processos

Como "turn" esta como 0, o processo 'a' no fica "preso" no while, e

assim executa a regio crtica, aps terminar, ele seta "turn" para 1 e parte para o

resto do cdigo, caso ocorra um chaveamento e o processo 'b' tente executar a

regio crtica antes que o processo 'a' sete "turn" como 1, ele ficara em um loop,

apenas testando a variavel "turn"(espera ativa).

3.3.5 Soluo de Peterson

Antes do processo entrar na regio crtica ele executa o

procedimento enter_region(), com o seu nmero. E aps sair da regio crtica,

executa leave_region().

3.3.6 Deadlock

Dois ou mais processos ficam irreversivelmente bloqueados.

3.3.7 Starvation

Um processo fica sempre no final na fila e no consegue ser

atendido, pois processos com maior prioridade "roubam" sua vez.

3.4 USABILIDADE DE INTERFACES PARA DISPOSITIVOS MVEIS

Um questionamento comumsobre as melhores prticas de front-end

/ usabilidade para dispositivos mveis o quanto elas so especficas ao contexto

mobile, pois muitas delas no se distinguem das diretrizes que vm sendo difundidash 20 anos.
http://pt.wikipedia.org/wiki/Sincronia_de_processoshttp://pt.wikipedia.org/wiki/Deadlockhttp://pt.wikipedia.org/wiki/Starvationhttp://pt.wikipedia.org/wiki/Ficheiro:Alternancia.jpghttp://pt.wikipedia.org/wiki/Starvationhttp://pt.wikipedia.org/wiki/Deadlockhttp://pt.wikipedia.org/wiki/Sincronia_de_processos


14/34

11

fato que grande parte das diretrizes so semelhantes, mas o que

muda a criticidade quando tratamos de mobile. Algumas recomendaes tornam-

se mais graves e imperdoveis quando no so seguidas no projeto de interfaces

para dispositivos mveis.

Como exemplo, podemos usar a questo da densidade

informacional. Em aplicaes que sero visualizadas em dispositivos mveis, os

textos devem ser concisos, eliminando informaes secundrias que podem ser

irrelevantes. Ora, mas isso tambm vale para aplicaes visualizadas em desktop!,

voc pensa. Porm, para mobile, a conciso deve ser ainda maior e informaes

que seriam aceitveis nas aplicaes web/desktop convencionais devem ser

removidas de aplicaes mobile. A diretriz base a mesma: reduzir informaosecundria. O que diferencia o grau de severidade que isto representa neste outro

cenrio.

3.4.1 Recomendaes Crticas Para o Projeto de Interfaces Mobile

Desenvolver sites e aplicaes para mobile requer ateno para

alguns critrios que tem um grande impacto na forma com que as pessoas

interagem com estes dispositivos.

3.4.1.1 Reduzir clicks

Esta parece ser uma recomendao bvia para ambiente mobile.

Porm, quem j desenvolveu para mobile ou utiliza aplicaes nestes dispositivos,

pense: voc j deve ter visto algum site que apresenta uma informao bem limitada

na primeira tela com um link de leia mais, onde voc tem o esforo de clicar e

esperar o carregamento do restante do contedo que voc necessita, que s vezes

poderia ser resumido em apenas uma tela.

Se em um projeto usual de interface as melhores prticas indicam

que seria mais adequado disponibilizar toda a informao necessria em uma nica

tela e poupar cliques do usurio, porque esta diferena em mobile? Por isso, deixar

o contedo mais conciso crucial para que a informao possa ser apresentada de

modo objetivo e o menos fragmentada possvel.


15/34

12

3.4.1.2 Reduzir funcionalidades

Restringir a quantidade de funcionalidades, mantendo as que so

necessrias ao ambiente mobile, diminui a chance dos usurios se confundirem

diante de todas as possibilidades e opes oferecidas.

3.4.1.3 Reduzir contedo

Devido ao tamanho das telas, o contedo para mobile exige uma

carga cognitiva maior e, portanto, pode ser at duas vezes mais difcil de

compreender. Como a memria de curto prazo fraca, quanto mais os usuriostiverem que rolar para se lembrar de um contedo, menos eles o faro.

3.4.1.4 Dar escolhas ao usurio

Textos mais concisos e funcionalidades mais restritas so

necessrios. Mas importante manter um link para a verso convencional do site,

caso o usurio precise acessar algum recurso que no esteja na verso mobile. O

usurio deve ter o direito de escolha sobre como ele deseja visualizar o site.

3.4.2 Outras Prticas Importantes Que Herdamos da Usabilidade Convencional

3.4.2.1 Integridade esttica

O quanto o design da sua aplicao se integra com a funo da

mesma. o casamento entre forma e funo, interface com boa qualidade esttica efuncional.

3.4.2.2 Consistncia

A consistncia de interface permite que o usurio transfira seus

conhecimentos e habilidades de uso de uma aplicao para outra. preciso frisar

que uma aplicao consistente no aquela que copia outras aplicaes. Pelo

contrrio, uma aplicao que tira proveito dos padres e paradigmas de interface

com os quais as pessoas se sentem mais confortveis durante a interao.


16/34

13

3.4.2.3 Metforas

Fcil reconhecimento e memorizao de palavras, smbolos e

imagens.

3.4.2.4 Contexto do usurio

Especificao do ambiente do usurio, incluindo tambm a

modelagem de anlise de tarefa e objetivos de negcio.

3.4.2.5 Modelo mental

Organizao apropriada de dados, funes, tarefas, papis e

pessoas de acordo com o modo com que o usurio compreende e reconhece estes

elementos.

3.4.2.6 Navegao

Navegao adequada considerando o modelo mental atravs dejanelas, menus, caixas de dilogos e painis de controle em formato compreensvel.

3.4.2.7 Interao e feedback

Input efetivo e feedback do output de informaes para assegurar ao

usurio que uma ao est em processamento.

3.4.2.8 Aparncia e design

Qualidade visual e ateno ao design com relao escala,

proporo, ritmo, simetria e balanceamento de componentes.

3.4.2.9 Visualizao de informaes

Apresentao de informaes por tabelas, grficos, mapas ediagramas. Uma vez que a tela destes dispositivos ainda pequena em comparao


17/34

14

aos computadores comuns (mesmo se tratando de tablets), preciso se valer de

componentes coringas que so capazes de apresentar uma boa quantidade de

informao de modo compacto, conciso, de fcil visualizao e acessvel.

3.5 JAVA DB E DISPOSITIVOS MVEIS

O nmero atual de SGBDs que os desenvolvedores podem usar

extenso, porm, se filtrarmos por SGBDs que tambm possam ser usados no

ambiente mvel, este nmero cai drasticamente. Neste pequeno texto, iremos falar

brevemente do Java DB, um banco de dados 100% Java que pode ser usado na

plataforma Java SE, Java EE e, inclusive na Java ME. O Java DB comeou em1996, com o projeto Cloudscape, em 2004 foi incorporado ao projeto Apache. Sua

ideia tem muitos pontos em comum com o DB2, tendo limites e caractersticas

semelhantes.

Para quem j utiliza a linguagem Java, esta pode ser uma tima

opo, porque o Java DB construdo 100% Java, alm de ser recomendado pela

Sun. Outras caractersticas importantes do banco de dados:

Suporte ao JDBC 4; Simples de embarcar em uma aplicao (basta colocar o

derby.jar no classpath de sua aplicao);

Administrao zero para dispositivos mveis e muito simples

para uso desktop;

Tamanho mdio de 2MB.

E sobre a possibilidade de sua utilizao com o Java ME? Porque o

RMS ainda existe? Calma, infelizmente o Java DB ainda no est disponvel para a

configurao CLDC, somente para a CDC, verso 1.1. H alguns pontos importantes

que precisam ser conhecidos. Se a verso do seu Java DB menor que a 10.1.1,

no existe suporte para a Java ME. Se a verso maior que a 10.1.1 e menor que a

10.3.1.4, CDC/FP 1.0 tambm suportado. O Java DB tem suporte ao perfil

Foundation Profile (FP) da CDC, sendo assim, ela tambm oferece suporte aos

perfis que so subconjuntos da FP, como o PersonalBasis Profile.

A codificao mais prxima do uso JDBC no Java SE, do que a

persistncia de dados com o Record Management System. Veja este pequeno

trecho de cdigo:


18/34

15

1: EmbeddedSimpleDataSourceds = new EmbeddedSimpleDataSource();2: String dbName = "simpleMobileDB";3: ds.setDatabaseName(dbName);4: ds.setCreateDatabase("create");5:6: Connection conn = null;7: Statement s = null;8: PreparedStatementps = null;9: ResultSetrs = null;10:11: try {12: conn = ds.getConnection();13: s = conn.createStatement();

14:15: s.execute("create table streetaddr(numint, addrvarchar(40))");16:17: s.execute("insert into streetaddr values (1956, 'Dado')");18:19: ps = conn.prepareStatement("update streetaddr set num=?, addr=?

wherenum=?");20:21: ps.setInt(1, 180);22: ps.setString(2, "Grand Ave.");

23: ps.setInt(3, 1956);24: ps.executeUpdate();25:26: } catch (SQLException e) {}

O uso do Java DB no Java SE permite o uso da classe

java.sql.DriverManager, porm, no Java ME, necessrio utilizar a classe

EmbeddedSimpleDataSource(linha 1). A linha 2 especifica o nome do database, a

linha 3 configura o nome da base de dados que ser acessada pelo Java DB. A linha

4 permite que o database seja criado automaticamente se ele no existir.

As linhas seguintes do cdigo servem apenas para mostrar que o

uso do Java DB no ambiente ME se assemelha em muito com o ambiente desktop,

inclusive utilizando chamadas SQL.

Infelizmente, o Java DB ainda no est disponvel na configurao

CLDC, ento, teremos que conviver com o RMS mais algum tempo, ou, com o

Floggy e outros frameworks que facilitam a persistncia de dados. Porm, assim

como o uso de smartphones cresce exponencialmente, a implementao da CDC

pode ser implementada em um nmero de dispositivos bem maior do que o


19/34

16

atual.Sendo assim, interessante, como programadores Java ME, conhecermos, ao

menos que a essncia, deste banco de dados chamados Java DB.


20/34

17

4 GESTO E SEGURANA NO SISTEMA DE INFORMAO

4.1 ENGENHARIA SOCIAL

Em Segurana da informao, chama-se Engenharia Socialas

prticas utilizadas para obter acesso a informaes importantes ou sigilosas em

organizaes ou sistemas por meio da enganao ou explorao da confiana das

pessoas. Para isso, o golpista pode se passar por outra pessoa, assumir outra

personalidade, fingir que um profissional de determinada rea, etc. uma forma

de entrar em organizaes que no necessita da fora bruta ou de erros em

mquinas. Explora as falhas de segurana das prprias pessoas que, quando notreinadas para esses ataques, podem ser facilmente manipuladas.

Engenharia social compreende a inaptido dos indivduos

manterem-se atualizados com diversas questes pertinentes a tecnologia da

informao, alm de no estarem conscientes do valor da informao que eles

possuem e, portanto, no terem preocupao em proteger essa informao

conscientemente. importante salientar que, a engenharia social aplicada em

diversos setores da segurana da informao independente de sistemas

computacionais, software e ou plataforma utilizada, o elemento mais vulnervel de

qualquer sistema de segurana da informao o ser humano, o qual possui traos

comportamentais e psicolgicos que o torna suscetvel a ataques de engenharia

social. Dentre essas caractersticas, pode-se destacar:

Vaidade pessoal e/ou profissional: O ser humano costuma ser

mais receptivo a avaliao positiva e favorvel aos seus objetivos, aceitando

basicamente argumentos favorveis a sua avaliao pessoal ou profissional ligada

diretamente ao benefcio prprio ou coletivo de forma demonstrativa.

Autoconfiana: O ser humano busca transmitir em dilogos

individuais ou coletivos o ato de fazer algo bem, coletivamente ou individualmente,

buscando transmitir segurana, conhecimento, saber e eficincia, buscando criar

uma estrutura base para o incio de uma comunicao ou ao favorvel a uma

organizao ou indivduo.

Formao profissional: O ser humano busca valorizar sua

formao e suas habilidades adquiridas nesta faculdade, buscando o controle em

uma comunicao, execuo ou apresentao seja ela profissional ou pessoal


21/34

18

buscando o reconhecimento pessoal inconscientemente em primeiro plano.

Vontade de ser til: O ser humano, comumente, procura agir com

cortesia, bem como ajudar outros quando necessrio.

Busca por novas amizades: O ser humano costuma se agradar e

sentir-se bem quando elogiado, ficando mais vulnervel e aberto a dar informaes.

Propagao de responsabilidade: Trata-se da situao na qual o

ser humano considera que ele no o nico responsvel por um conjunto de

atividades.

Persuaso: Compreende quase uma arte a capacidade de

persuadir pessoas, onde se busca obter respostas especficas. Isto possvel

porque as pessoas possuem caractersticas comportamentais que as tornam

vulnerveis a manipulao.

Exemplos de ataques usando engenharia social:

Exemplo 1: Voc recebe uma mensagem de recadastramento de

senhas do e-mail institucional, mesmo sabendo que a DGTI nunca faz esse tipo de

solicitao via e-mail.

Exemplo 2: voc recebe uma mensagem e-mail, onde o

remetente o gerente ou algum em nome do departamento de suporte do seu

banco. Na mensagem ele diz que o servio de Internet Banking est apresentando

algum problema e que tal problema pode ser corrigido se voc executar o aplicativo

que est anexado mensagem. A execuo deste aplicativo apresenta uma tela

anloga quela que voc utiliza para ter acesso a conta bancria, aguardando que

voc digite sua senha. Na verdade, este aplicativo est preparado para furtar sua

senha de acesso a conta bancria e envi-la para o atacante.

Exemplo 3: voc recebe uma mensagem de e-mail, dizendo queseu computador est infectado por um vrus. A mensagem sugere que voc instale

uma ferramenta disponvel em um site da Internet, para eliminar o vrus de seu

computador. A real funo desta ferramenta no eliminar um vrus, mas sim

permitir que algum tenha acesso ao seu computador e a todos os dados nele

armazenados.

Exemplo 4: algum desconhecido liga para a sua casa e diz ser do

suporte tcnico do seu provedor. Nesta ligao ele diz que sua conexo com aInternet est apresentando algum problema e, ento, pede sua senha para corrigi-la.


22/34

19

Caso voc entregue sua senha, este suposto tcnico poder realizar uma infinidade

de atividades maliciosas, utilizando a sua conta de acesso Internet e, portanto,

relacionando tais atividades ao seu nome.

Estes casos mostram ataques tpicos de engenharia social, pois os

discursos apresentados nos exemplos procuram induzir o usurio a realizar alguma

tarefa e o sucesso do ataque depende nica e exclusivamente da deciso do

usurio em fornecer informaes sensveis ou executar programas.

4.1.1 Evitando a Engenharia Social

Especialistas afirmam que a medida que nossa sociedade torna-secada vez mais dependente da informao, a engenharia social tende a crescer e

constituir-se numa das principais ameaas aos sistemas de segurana das (grandes)

organizaes. Entretanto, embora as situaes apresentadas acima sejam um tanto

indesejveis e at certo ponto assustadoras, h mecanismos atravs dos quais uma

organizao pode implementar a fim de detectar e prevenir ataques de engenharia

social. Tais medidas visam, principalmente, atenuar a participao do componente

humano. Essas medidas compreendem:

Educao e TreinamentoImportante conscientizar as pessoas

sobre o valor da informao que elas dispem e manipulam, seja ela de uso pessoal

ou institucional. Informar os usurios sobre como age um engenheiro social.

Segurana Fsica Permitir o acesso a dependncias de uma

organizao apenas s pessoas devidamente autorizadas, bem como dispor de

funcionrios de segurana a fim de monitorar as entradas e sadas de locais

estratgicos dentro da organizao.

Poltica de Segurana Estabelecer procedimentos que

eliminem quaisquer trocas de senhas. Por exemplo, um administrador jamais deve

solicitar a senha e/ou ser capaz de ter acesso a senha de usurios de um sistema.

Estimular o uso de senhas de difcil descoberta, alm de remover contas de usurios

que deixaram a instituio.

Controle de Acesso Os mecanismos de controle de acesso

tem o objetivo de implementar privilgios mnimos a usurios a fim de que estes

possam realizar suas atividades. O controle de acesso pode tambm evitar que

usurios sem permisso possam criar/remover/alterar contas e instalar softwares


23/34


24/34

21

surge do erro de tamanho do buffer, uma regio da memria reservada para escrita

e leitura dos dados.

M configurao Aplicativos de segurana, como o firewall,

devem ser corretamente configurados, ou podem ser brechas para ataques

maliciosos.

Falha humana Execuo de arquivos maliciosos

manualmente.

4.2.3 Principais Objetivos da Anlise de Vulnerabilidades

Identificar e tratar falhas de softwares que possam comprometerseu desempenho, funcionalidade e segurana;

Providenciar uma nova soluo de segurana como, por

exemplo, o uso de um bom antivrus, com possibilidade de update constante;

Alterar as configuraes de softwares a fim de torn-los mais

eficientes e menos suscetveis a ataques;

Utilizar mecanismos para bloquear ataques automatizados

(worms, bots, entre outros); Implementar a melhoria constante do controle de segurana;

Documentar os nveis de segurana atingidos para fins de

auditoria eCompliance com leis, regulamentaes e polticas.

A Anlise de Vulnerabilidades torna a tomada de deciso em relao

segurana mais fcil, pois rene informaes essenciais que indicam a melhor

estratgia para se manter protegido de falhas, ataques e invases. Alm disso, uma

das facilidades obtidas atravs da implementao de polticas de segurana descobrir e tratar vulnerabilidades com maior rapidez, possibilitando o alinhamento

s normas de compliance.

4.3 AMEAAS, ATAQUES E VULNERABILIDADES

Ameaa: Quem pode atacar qual componente, usando qual

recurso, com que objetivo em mente, quando, de onde, porque, e qual a

probabilidade disso acontecer. Podendo conter aspectos gerais da natureza do

ataque, mas no detalhes, tais como quais medidas de segurana ele deve superar
http://www.modulo.com.br/solucoes/gestao-de-compliancehttp://www.modulo.com.br/solucoes/gestao-de-compliance


25/34

22

e quais vulnerabilidades explorar.

Avaliao de Ameaa (TA, do ingls ThreatAssessment):

Tentativa de prever as ameaas. Podendo envolver o uso de conhecimentos sobre

incidentes de segurana antigos em uma estrutura semelhante a avaliada. Criar uma

segurana proativa (e no s reativa) para ameaas que ainda no se

materializaram.

Vulnerabilidade: Uma fraqueza na segurana do sistema (ou

falta de medidas de segurana) que pode ser explorada por diferentes adversrios

com diferentes interesses.

Avaliao de Vulnerabilidade (VA, do ingls

VulnerabilityAssessment): Tentativa de descobrir (e talvez demonstrar)

vulnerabilidades de segurana que poderiam ser exploradas por um adversrio. Uma

boa avaliao de vulnerabilidade normalmente sugere contramedidas viveis ou

melhorias na segurana para eliminar ou mitigar a vulnerabilidade, tambm ajuda na

recuperao aps um ataque e que no se repita.

Gesto de risco: Tentativa de minimizar as fontes de riscos de

segurana decidindo como implantar, modificar, ou reatribuir recursos de segurana.

Utiliza como entrada para as decises os resultados da TA, da VA, os ativos a seremprotegidos (informaes dos clientes, reputao do sistema, etc.), as consequncias

de ataques bem sucedidos, e os recursos (tempo, financiamento, pessoal)

disponveis para providenciar segurana.

Ataque: Uma tentativa de causar danos a ativos valiosos,

normalmente tentando explorar uma ou mais vulnerabilidades. O dano pode incluir

roubo de informaes, sabotagem (defacement, backdoor, etc.), destruio (apagar

banco de dados, cdigos), espionagem, ou adulterao. Para mais exemplos sver as notcias.

4.3.1 Alguns Exemplos de Ameaas e Vulnerabilidades

Ameaa: Adversrios podem instalar malware nos

computadores da organizao permitindo que eles possam roubar informaes

pessoais para fingir ser outra pessoa.

Vulnerabilidade: Os computadores da organizao no possuem

as ltimas definies do banco de dados de vrus para o software anti-malware.


26/34

23

Ameaa: Cyber Criminosos podem invadir o sistema e roubar o

banco de dados.

Vulnerabilidade: A plataforma em que o sistema funciona

permite escalar privilgios.

Ameaa: Um funcionrio mal instrudo pode revelar informaes

confidenciais aos adversrios.

Vulnerabilidade: Funcionrios no tem um bom entendimento de

qual informao sensvel/confidencial e qual no , logo eles no podem fazer um

bom trabalho protegendo-as de engenharia social.

Ameaa: Funcionrios descontentes podem sabotar o sistema.

Vulnerabilidade: A organizao carece de contramedidasefetivas para ameaas internas como verificao do passado e mitigao de

descontentamento de funcionrios (tratamento justo de funcionrios, processos

legtimos de resolver reclamaes, programas de assistncia aos funcionrios, no

toleramento de chefes opressores, etc.)

Ameaa: Advanced persistentthreat (APT) podem tomar o

controle do ambiente corporativo.

Vulnerabilidade: A organizao carece de uma defesaestratgica organizada com potencial de tomar atitudes bem pensadas e

nos momentos certos.

Mitigar uma vulnerabilidade pode no ser relevante para uma

ameaa, pois o adversrio pode no perceber uma vulnerabilidade. Vulnerabilidades

no definem ameaas, pois um adversrio deseja efetuar um ataque por um motivo

externo.

TAs e VAs so diferentes, e ambas so necessrias para se ter umaboa gesto de risco, e ambas so dependentes entre si at certo ponto. Hackers

procuram explorar vulnerabilidades, cuja ausncia levaria a seu fracasso. Assim

como no teria relevncia a existncia de vulnerabilidades se no existissem

ameaas. No existe uma relao de um para um entre vulnerabilidades e ameaas.

Diferentes adversrios podem explorar uma mesma vulnerabilidade para diferentes

objetivos, por exemplo, um computador desatualizado. Assim como uma ameaa

pode explorar vrias vulnerabilidades diferentes para atingir o seu objetivo.

TA envolve em sua maioria especular sobre pessoas que no esto

em nossa frente, e que podem muito bem no existir, mas que possuem motivaes
http://en.wikipedia.org/wiki/Advanced_Persistent_Threathttp://www.infoworld.com/d/security-central/your-guide-the-seven-types-malicious-hackers-636?page=0,0&source=IFWNLE_nlt_sec_2011-02-08http://www.infoworld.com/d/security-central/your-guide-the-seven-types-malicious-hackers-636?page=0,0&source=IFWNLE_nlt_sec_2011-02-08http://www.infoworld.com/d/security-central/your-guide-the-seven-types-malicious-hackers-636?page=0,0&source=IFWNLE_nlt_sec_2011-02-08http://www.infoworld.com/d/security-central/your-guide-the-seven-types-malicious-hackers-636?page=0,0&source=IFWNLE_nlt_sec_2011-02-08http://en.wikipedia.org/wiki/Advanced_Persistent_Threat


27/34

24

complexas, objetivos, mentalidades e recursos. Vulnerabilidades, por outro lado, so

mais concretas se formos espertos e criativos o suficiente para v-las. Elas so

descobertas atravs de uma anlise da estrutura e sua segurana, sem

especulaes sobre pessoas.

Por esse motivo, o entendimento das vulnerabilidades

normalmente mais fcil que as ameaas. Algumas pessoas afirmam que os

incidentes anteriores de segurana nos dizem tudo o que precisamos saber sobre as

ameaas, mas isso ser reativo, no proativo, e deixa escapar raros, mas

catastrficos ataques.

Argumenta-se que o conhecimento das vulnerabilidades mais

poderoso que o das ameaas. Pois ao pr um razovel esforo para mitigar asvulnerabilidades, voc provavelmente estar em boa forma para qualquer que seja a

ameaa(que muito mais fcil de errar). E ser ignorante nas vulnerabilidades

permite aos adversrios vrios formas de atingir seu objetivo.

Mas em qualquer grande e complexo sistema existe um enorme

nmero de vulnerabilidades. E encontrar vulnerabilidades exige uma anlise

minuciosa e imaginao/criatividade, podendo chegar a um custo altssimo. Alm de

que infelizmente entramos em situaes inevitveis em que no podemos ter contatocom o cdigo fonte de um componente do nosso sistema, nos tornando

dependentes de patchs que podem demorar a chegar.

A avaliao das ameaas, ao contrrio, normalmente carece de uma

anlise criativa sobre os problemas de segurana caracterizada pelo uso simplrio

de listas de verificao, auditorias de conformidade dos logs, diretrizes a serem

seguidas, bases de dados de incidentes de segurana passado e abordagens

generalizadas.Finalizando, no devemos confundir a inteno de uma TA ou VA.

No serve para certificar ou medir a segurana, ou como uma tcnica para descobrir

se algum no est fazendo algo direito. O objetivo de uma VA de melhorar a

segurana. O objetivo de uma TA nos ajudar a decidir (junto com a gesto de

risco) o que e quanto de segurana ns precisamos. Pois mesmo aps as

avaliaes, ainda existir ameaas e vulnerabilidades desconhecidas e no tratadas.

O jeito encarar que no poderemos ficar completamente protegidos,e utilizar as

avaliaes para atingirmos a segurana exigida.
http://0xmateusbraga.wordpress.com/2010/10/07/completamente-protegido/http://0xmateusbraga.wordpress.com/2010/10/07/completamente-protegido/


28/34

25

4.4 MEDIDAS DE SEGURANA E POLTICA DE SEGURANA

A segurana dos sistemas informticos limita-se geralmente a

garantir os direitos de acesso aos dados e recursos de um sistema implementando

mecanismos de autenticao e de controlo que permitem garantir que os utilizadores

dos ditos recursos possuem unicamente os direitos que lhes foram concedidos.

Os mecanismos de segurana implementados podem, no entanto

provocar um embarao a nvel dos utilizadores e as instrues e regras tornam-se

cada vez mais complicadas medida que a rede se estender. Assim, a segurana

informtica deve ser estudada de maneira a no impedir os utilizadores de

desenvolver os usos que lhes so necessrios, e de fazer de modo a que possamutilizar o sistema de informao em total confiana.

a razo pela qual necessrio definir inicialmente uma poltica de

segurana, cuja implementao se faz de acordo com as quatro etapas seguintes:

Identificar as necessidades em termos de segurana, os riscos

informticos que pesam sobre a empresa e as suas eventuais consequncias;

Elaborar regras e procedimentos a implementar nos diferentes

servios da organizao para os riscos identificados; Supervisionar e detectar as vulnerabilidades do sistema de

informao e manter-se informado das falhas sobre as aplicaes e materiais

utilizados;

Definir as aes a empreender e as pessoas a contatar em caso

de deteco de uma ameaa.

A poltica de segurana , por conseguinte o conjunto das

orientaes seguidas por uma organizao (em sentido lato) em termos desegurana. A esse respeito ela deve ser elaborada a nvel dedireo da organizao

interessada, porque se refere a todos os utilizadores do sistema.

A esse respeito, no cabe s aos administradores informticos

definir os direitos de acesso dos utilizadores, mas aos responsveis hierrquicos

destes ltimos. O papel do administrador informtico , por conseguinte garantir que

os recursos informticos e os direitos de acesso a estes esto em coerncia com a

poltica de segurana definida pela organizao.

Alm disso, j que o nico a conhecer perfeitamente o sistema,

cabe-lhe fazer aumentar as informaes relativas segurana sua direo,


29/34

26

eventualmente aconselhar as instncias de deciso sobre as estratgias a aplicar,

bem como ser o ponto de entrada relativo comunicao destinada aos utilizadores

sobre os problemas e recomendaes em termos de segurana.

A segurana informtica da empresa assenta num bom

conhecimento das regras pelos empregados, graas a aes de formao e de

sensibilizao junto dos utilizadores, mas deve ir, alm disso, e nomeadamente

cobrir os seguintes campos:

Um dispositivo de segurana fsico e lgico, adaptado s

necessidades da empresa e aos usos dos utilizadores;

Um procedimento de gesto das atualizaes;

Uma estratgia desalvaguardacorretamente planificada;

Um plano de retoma aps incidente;

Um sistema documentado atualizado.

4.4.1 As causas da Insegurana

Distinguem-se geralmente dois tipos de insegurana:

O estado ativo de insegurana, ou seja, o no conhecimento peloutilizador das funcionalidades do sistema, algumas das quais lhe podem ser

prejudiciais (por exemplo, o fato de no desativar servios de redes no necessrias

ao utilizador);

O estado passivo de insegurana,ou seja, a ignorncia dos meios

de segurana implementados, por exemplo, quando o administrador (ou o utilizador)

de um sistema no conhece os dispositivos de segurana de que dispe.

4.5 AUDITORIA DE SISTEMAS DE INFORMAO

De maneira geral, um planejamento de auditoria deve identificar

problemas potenciais de segurana da entidade, com base na legislao vigente,

atividades e transaes da empresa de forma a propiciar o cumprimento dos

servios contratados com entidade dentro dos prazos e de forma segura,

estabelecendo a natureza, oportunidade e extenso dos exames a serem efetuados

em conjunto com os termos constantes na sua proposta de servios para a

realizao do trabalho.
http://pt.kioskea.net/contents/surete-fonctionnement/sauvegarde.php3http://pt.kioskea.net/contents/surete-fonctionnement/sauvegarde.php3


30/34

27

A auditoria de sistemas de informao visa verificar a conformidade

no dos aspectos contbeis da organizao, mas sim do prprio ambiente

informatizado, garantindo a integridade dos dados manipulados pelo computador.

Assim, ela estabelece e mantm procedimentos documentados para planejamento e

utilizao dos recursos computacionais da empresa, verificando aspectos de

segurana e qualidade. O trabalho da auditoria de sistemas acontece com o

estabelecimento de metodologias, objetivos de controle e procedimentos a serem

adotados por todos aqueles que operam ou so responsveis por equipamentos de

TI e/ou sistemas dentro da organizao.

Em uma auditoria os objetivos de controle so estabelecidos com

base nas atividades da entidade, seu tamanho, qualidade de seus sistemas econtrole interno e competncia de sua administrao. necessrio que o auditor

tenha um modelo normativo de como as atividades devem estar sendo feitas. Assim,

devem-se levar em conta as atividades das pessoas, rgos e produtos da entidade

de modo que tais atividades no se desviem das normas preestabelecidas pela

organizao.

Objetos de controle so metas de controle a serem alcanadas ou

efeitos negativos a serem evitados traduzidos em procedimentos de auditoria. Assimos objetivos de controle so detalhados conforme o enfoque ao qual est

relacionado. Existem diversas reas que esses objetivos podem contemplar como

segurana, atendimento s solicitaes externas, materialidade, altos custos de

desenvolvimento, grau de envolvimento dos usurios e outsourcing.

Segundo o COBIT, as metas a serem alcanadas em uma auditoria

de Sistemas de Informao se enquadraro em algum dos itens abaixo:

Estrutura de Gerenciamento de Programa; Estrutura de Gerenciamento de Projeto;

Abordagem de Gerenciamento de Projeto;

Comprometimento dos Participantes;

Escopo do Projeto;

Fase de Incio do Projeto;

Planejamento do Projeto Integrado;

Recursos do Projeto; Gerenciamento de Riscos do Projeto;
http://www.profissionaisti.com.br/category/seguranca/http://www.profissionaisti.com.br/category/seguranca/


31/34

28

Planejamento do Projeto Integrado;

Recursos do Projeto;

Gerenciamento de Riscos do Projeto;

Planejamento da Qualidade do Projeto;

Controle de Mudanas no Projeto;

Mtodos de Planejamento de Garantia do Projeto;

Avaliao, Relatrios e Monitoramento do Desempenho do

Projeto;

Concluso do Projeto.

Por fim, importante ressaltar que a necessidade de controlar e

auditar os recursos da tecnologia da informao e da comunicao nunca foi to

grande. Para garantir segurana e qualidade em seus processos e servios

necessrio verificao e controle constante.

4.5.1 O Auditor de Sistemas

O auditor de sistemas verifica a eficcia dos controles e

procedimentos de segurana existentes, a eficincia dos processos em uso, acorreta utilizao dos recursos disponveis, assessorando a administrao na

elaborao de planos e definio de metas, colaborando no aperfeioamento dos

controles internos, apontando deficincias e irregularidades que possam

comprometer a segurana e o desempenho organizacional.

Com a larga utilizao da tecnologia para o armazenamento das

informaes contbeis, financeiras e operacionais, o auditor de sistemas tem de se

aprimorar no campo de atuao (processos) da organizao para extrair, analisarbanco de dados envolvidos e suportar decises das demais reas deauditoria.

A necessidade global de referncias nesse assunto, para o exerccio

dessa profisso, promoveram a criao e desenvolvimento de melhores prticas

comoCOBIT,COSO,ISO 27001 eITIL.

Atualmente a certificao CISA CertifiedInformation Systems

Auditor, oferecida pela ISACA Information Systems andControlAssociation uma

das mais reconhecidas e avaliadas por organismos internacionais, j que o processo

de seleo consta de uma prova extensa que requer conhecimentos avanados,

alm de experincia profissional e a necessidade de manter-se sempre atualizado,
http://www.profissionaisti.com.br/category/qualidade/http://pt.wikipedia.org/wiki/Banco_de_dadoshttp://pt.wikipedia.org/wiki/Auditoriahttp://pt.wikipedia.org/wiki/COBIThttp://pt.wikipedia.org/wiki/COSOhttp://pt.wikipedia.org/wiki/ISO_27001http://pt.wikipedia.org/wiki/ITILhttp://pt.wikipedia.org/wiki/CISAhttp://pt.wikipedia.org/wiki/ISACAhttp://pt.wikipedia.org/wiki/ISACAhttp://pt.wikipedia.org/wiki/CISAhttp://pt.wikipedia.org/wiki/ITILhttp://pt.wikipedia.org/wiki/ISO_27001http://pt.wikipedia.org/wiki/COSOhttp://pt.wikipedia.org/wiki/COBIThttp://pt.wikipedia.org/wiki/Auditoriahttp://pt.wikipedia.org/wiki/Banco_de_dadoshttp://www.profissionaisti.com.br/category/qualidade/


32/34

29

atravs de uma poltica de educao continuada (CPE) na qual o portador da

certificao deve acumular carga horria de treinamento por perodo estabelecido.

A formao acadmica do auditor de sistemas pelos motivos acima

acaba sendo multidisciplinar: anlise de sistemas, cincia de computao,

administrao com nfase em TI, advocacia com foco em Direito da informtica -

direito digital e correlatos.
http://pt.wikipedia.org/wiki/Direito_da_inform%C3%A1ticahttp://pt.wikipedia.org/wiki/Direito_da_inform%C3%A1tica


33/34

30

5 CONCLUSO

A pesquisa para a realizao deste trabalho trouxe uma ideia dos

vrios recursos para dispositivos mveis, threads, sincronismo de processos,

interface com os usurios e sobre o Java DB, entre outros, um banco de dados

100% Java que pode ser usado no ambiente mvel.

A utilizao para atender a gesto e segurana dos sistemas de

informao, foi observada que a engenharia social um meio utilizado para obter

acesso a informaes importantes ou sigilosas em organizaes ou sistemas por

meio da enganao ou explorao da confiana das pessoas. Critrios foram

estudados como, vulnerabilidades, ameaas e ataques, medidas de segurana,polticas de segurana e auditoria, notando que segurana dos sistemas limita-se

geralmente a garantir os direitos de acesso aos dados e recursos de um sistema

implementando mecanismos de autenticao e de controlo que permitem garantir

que os utilizadores dos recursos possuem unicamente os direitos que lhes foram

concedidos.


34/34

31

REFERNCIAS

http://pt.wikipedia.org/wiki/Arranjo_(computa%C3%A7%C3%A3o)

Acessado em 03/09/2014

https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Array

Acessado em: 03/09/2014

http://www.java.com/pt_BR/download/help/jcp_security.xmlAcessado em: 03/09/2014

http://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-que-

e-e-para-que-serve-a-analise-de-vulnerabilidades-Acessado em: 03/09/2014

http://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikpAcessado em: 03/09/2014

http://pt.wikipedia.org/wiki/Sincronia_de_processosAcessado em: 03/09/2014

Protocolo=160385244
http://pt.wikipedia.org/wiki/Arranjo_(computa%C3%A7%C3%A3o)http://pt.wikipedia.org/wiki/Arranjo_(computa%C3%A7%C3%A3o)https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Arrayhttps://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Arrayhttps://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Arrayhttp://www.java.com/pt_BR/download/help/jcp_security.xmlhttp://www.java.com/pt_BR/download/help/jcp_security.xmlhttp://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-que-e-e-para-que-serve-a-analise-de-vulnerabilidades-http://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-que-e-e-para-que-serve-a-analise-de-vulnerabilidades-http://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-que-e-e-para-que-serve-a-analise-de-vulnerabilidades-http://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikphttp://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikphttp://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikphttp://pt.wikipedia.org/wiki/Sincronia_de_processoshttp://pt.wikipedia.org/wiki/Sincronia_de_processoshttp://pt.wikipedia.org/wiki/Sincronia_de_processoshttp://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikphttp://tableless.com.br/usabilidade-de-interfaces-para-dispositivos-moveis-parte1/#.Ujhf7z8pikphttp://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-que-e-e-para-que-serve-a-analise-de-vulnerabilidades-http://www.modulo.com.br/solucoes/gestao-de-riscos-e-vulnerabilidades-de-ti-/o-que-e-e-para-que-serve-a-analise-de-vulnerabilidades-http://www.java.com/pt_BR/download/help/jcp_security.xmlhttps://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Arrayhttps://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Arrayhttp://pt.wikipedia.org/wiki/Arranjo_(computa%C3%A7%C3%A3o)

Documents

Atividade-Interdisciplinar-6º-Semestre-Individual.docx