C.E.S.A.

R - CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

CLOVES ALBERTO CHAVES DE LIMA

UM MODELO DE GERENCIAMENTO DE IDENTIDADE PARA SEGURANA DE APLICATIVOS SAAS

RECIFE, 2012

ii

C.E.S.A.R CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

UM MODELO DE GERENCIAMENTO DE IDENTIDADE PARA SEGURANA DE APLICATIVOS SAAS

Monografia apresentada ao programa de Especializao de Segurana em Engenharia de Software do Centro de Estudos e Sistemas Avanados do Recife C.E.S.A.R, como requisito para a obteno do ttulo de Especialista em Engenharia de Software com nfase em Segurana. Orientao: Prof. Vinicius Cardoso Garcia

RECIFE, 2012

iii

C.E.S.A.R CENTRO DE ESTUDOS E SISTEMAS AVANADOS DO RECIFE

UM MODELO DE GERENCIAMENTO DE IDENTIDADE PARA SEGURANA DE APLICATIVOS SAAS CLOVES ALBERTO CHAVES DE LIMA

Monografia apresentada ao programa de Especializao de Segurana em Engenharia de Software do Centro de Estudos e Sistemas Avanados do Recife C.E.S.A.R, como requisito para a obteno do ttulo de Especialista em Engenharia de Software com nfase em Segurana.

Data de aprovao: _____ / _____ / 2012.

Banca examinadora:

_____________________________
Prof.(a).Dr.(a) C.E.S.A.R - Centro de Estudos e Sistemas Avanados do Recife

_____________________________
Prof.(a).Dr.(a) C.E.S.A.R - Centro de Estudos e Sistemas Avanados do Recife

_____________________________
Prof.(a).Dr.(a) C.E.S.A.R - Centro de Estudos e Sistemas Avanados do Recife

iv

A meus dois grandes amores (me e noiva), que me deram fora necessria na hora certa, acreditaram que eu era capaz e no me deixaram desanimar em nenhum momento. Obrigado por tudo amo vocs!.

AGRADECIMENTOS

Este trabalho o culminar de um percurso de crescimento pessoal no qual o contributo de algumas pessoas se revelou fundamental. Impe-se, por isso, expressar neste espao, o meu reconhecimento. Primeiramente a Deus, que a razo principal de minha existncia e pela oportunidade que ele tem proporcionado a mim, de concluir mais uma etapa de minha vida, pois, sem ele, tudo que se foi feito no se faria. A minha querida me Messelene de Ftima , que foi minha inspirao pela sua histria de vida e que sempre acreditou que seria possvel, confiando em mim quando nem eu mesmo acreditava. A minha futura esposa Elizabeth Arajo que sempre esteve comigo, nas horas boas e difceis, que no momento de fraqueza quando estava prestes a desistir me fez entender que era possvel persistir, e que sempre entendeu a minha ausncia como sendo uma etapa passageira de minha vida, e por esse motivo que estou aqui, te amo. Ao meu orientador Vinicius Cardoso pela pacincia e sabedoria. Em fim, agradeo a todos os amigos que diretamente ou indiretamente ajudaram a concluir esse trabalho. Comear para muitos, continuar para poucos e terminar para VITORIOSOS.

vi

RESUMO

O aumento exponencial do poder de processamento, o amadurecimento da virtualizao, arquiteturas orientadas a servios e uma maior largura de banda, forneceram subsdios para um novo paradigma de software denominado de SaaS (Software as a Service), um modelo de fornecimento de software que permite aos clientes acesso s funcionalidades de negcio remotamente atravs da Internet (SUN, 2007). Este novo modelo traz a seus clientes novas perspectivas e uma nova maneira de reduzir os custos. J para os fornecedores propicia novos horizontes de investimento. Por outro lado, mesmo com este crescimento exponencial o meio usado para a utilizao deste servio ainda bastante vulnervel Este trabalho um estudo de reviso bibliogrfica que tem como objetivo abordar o modelo SaaS, descrevendo assim a arquitetura, vantagens e desvantagens, os modelo econmico, e suas vises. Por fim, estudaremos as vulnerabilidades deste servio e as principais dvidas encontradas no momento da escolha de tal modelo. Apresentaremos tambm, os mtodos de gerenciamento de identidade e meios de gerenciamento de controles para fornecer maior segurana para a escolha deste aplicativo, tais propostas sero mostradas atravs de estruturas UML.

Palavras-chave SaaS, gerenciamento de identidade, segurana, ameaas, vulnerabilidades.

vii

ABSTRACT

The exponential increase in processing power, the maturing of virtualization, service-oriented architectures and greater bandwidth, provide subsidies for a new software paradigm called SaaS (Software as a Service), a software delivery model that allows customers access to business functionality remotely via the Internet (SUN, 2007). This new model brings new prospects and customers a new way to reduce costs. As for the vendors provides new investment horizons. On the other hand, even with this exponential growth in the medium used for the use of this service is still quite vulnerable This paper is a literature review that aims to address the SaaS model, describing the architecture, advantages and disadvantages, the economic model , and their views. Finally, we study the vulnerabilities of the service and found the main questions when choosing such a model. We will also present the methods of identity management and media management controls to provide greater security for the choice of this application, such proposals will be shown using UML structures.

Key-words SaaS, identity management, security threats, vulnerabilities.

viii

LISTA DE FIGURAS

FIGURA 1 - ESTRUTURA DO MODELO SAAS RELAO COM MODELO DE NEGCIO, ARQUITETURA DA APLICAO E ESTRUTURA OPERACIONAL. FONTE: CHONG ET AL (2006) FIGURA 2- PARTILHA DE CUSTOS DE AMBIENTE TRADICIONAL DE TI. FONTE: CHONG ET AL (2006) FIGURA 3 - DIVISO TPICA DE INVESTIMENTO EM AMBIENTES SAAS. FONTE: CHONG ET AL (2006) FIGURA 4 - SAAS VANTAGEM DE CUSTO SOBRE SERVIDOR BASEADO EM SISTEMAS TRADICIONAIS. FONTE: BRIVO, 2009 FIGURA 5 - ANALISE DE CUSTO INSTALAO DE SISTEMAS BASEADO EM SERVIDOR E SAAS. FONTE: BRIVO, 2006 FIGURA 6 - CONCEITO DE CALDA LONGA. FONTE: ANDERSON (2006). FIGURA 7 - ABORDAGEM USANDO UM BANCO DE DADOS DISTINTO PARA CADA INQUILINO. FONTE: WOLTER ET AL. (2006). FIGURA 8 - ABORDAGEM EM QUE CADA INQUILINO POSSUI SEU PRPRIO CONJUNTO DE TABELAS NUMA MESMA BASE DE DADOS. FONTE: WOLTER ET AL.(2006). FIGURA 9 - CICLO DE VIDA DO DESENVOLVIMENTO SAAS. FONTE: KOMMALAPATI (2011). FIGURA 10 - USURIO E PERMISSES CONTIDAS EM BANCO DE DADOS INDEPENDENTE. FONTE: SOFTWARE (2008). FIGURA 11 - MODELO DE GERNCIA DE USURIO FIGURA 12 - DIAGRAMA GERENCIAMENTO DE INSERO DE CADASTRO FIGURA 13 - DIAGRAMA DE SEQUNCIA DE GERENCIAMENTO DE PERMISSES. FIGURA 14 - DIAGRAMA DE SEQUNCIA DE AUTENTICAO DO USURIO FINAL. FIGURA 15 - USO DO SSO. FONTE: (SOFTWARE, 2008). FIGURA 16 - DIAGRAMA DE CASO DE USO LOG. FIGURA 17 - GERENCIAMENTO DE LOG. FONTE: MOTA, 2009.

4 5 7 10 11 13 22 23 24 36 37 40 41 44 46 48 49

ix

LISTA DE TABELAS
TABELA 1- GERNCIA DE USURIO. TABELA 2- AUTENTICAR USURIO. 39 43

LISTA DE SIGLAS

Sigla SaaS TI SOA LAN VPN BPO TCO SLA SOAP XML POP IMAP HTTP SSO SAML STS LDAP

Significado Software as a Service Tecnologia da Informao Service-Oriented Architecture Local Area Network Virtual Private Network Business Process Outsourcing Total Cost of Ownership Service-Level Agreement Simple Object Access Protocol Extensible Markup Language Post Office Protocol Internet Message Access Protocol Hypertext Transfer Protocol Single-Sign-On Security Assertion Markup Language Security Token Service Lightweight Directory Access Protocol

xi

SUMRIO

LISTA DE FIGURAS .................................................................................................................. VIII LISTA DE TABELAS ................................................................................................................... IX LISTA DE SIGLAS ........................................................................................................................ X SUMRIO..................................................................................................................................... XI 1 2 INTRODUO ...................................................................................................................... 1 DEFINIO SOFTWARE AS A SERVICE SAAS ............................................................ 4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3 CONCEITOS DE SOFTWARE COMO SERVIO ......................................................... 7 ANLISE DE CUSTO .................................................................................................... 9 CONCEITO CAUDA LONGA APLICADA SAAS ......................................................... 11 SLA - SERVICE LEVEL AGREEMENTS ..................................................................... 13 VANTAGENS E DESVANTAGENS............................................................................. 15 SAAS VERTICAL E HORIZONTAL ............................................................................. 16 SAAS CORPORATIVO ............................................................................................... 17

ARQUITETURA SAAS ....................................................................................................... 18 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 CICLO DE DESENVOLVIMENTO ............................................................................... 19 SEGURANA SAAS ................................................................................................... 26 GESTO DE RISCOS SAAS ....................................................................................... 28 VULNERABILIDADES SAAS ...................................................................................... 28 MAU COMPORTAMENTO DO SERVIO .................................................................. 29 COMPUTAO CONFIVEL ..................................................................................... 29 VIOLAO DOS DADOS DOS CLIENTES ................................................................. 30 COMPARTILHAMENTO DE RECURSOS .................................................................. 31 AMEAAS A REDE ..................................................................................................... 31 AUTENTICAO ........................................................................................................ 32

GERENCIAMENTO NO CLICO DE VIDA DE DESENVOLVIMENTO SAAS .................... 34 4.1 GERENCIAMENTO DE IDENTIDADES ...................................................................... 35 4.2 MODELO DE GERENCIAMENTO DE USURIO PARA AUTENTICAO CENTRALIZADA ..................................................................................................................... 35 4.3 MODELO DE GERENCIAMENTO DE USURIO PARA AUTENTICAO DECENTRALIZADA ................................................................................................................ 44 4.4 MODELO DE GERENCIAMENTO DE LOG ................................................................ 46

5 6

CONCLUSO ..................................................................................................................... 51 REFERNCIAS ................................................................................................................... 53

1 INTRODUO
Software as a Service (SaaS) caminha para se tornar um dos segmentos de tecnologia da informao que mais cresce, principalmente, porque prov para as empresas uma alternativa mais barata do que os softwares tradicionais. Antes do surgimento do SaaS, as empresas no tinham outra opo seno hospedar seus softwares em suas prprias infraestruturas, rodando-os em seus servidores, o que gerava altos gastos com licenciamento de software e tambm com o parque tecnolgico. Segundo (DAS et al., 2010), SaaS uma forma de entregar as funcionalidades de software atravs da Internet a partir de uma nica instncia de aplicao, sendo compartilhada entre todos os usurios uma nica cpia de software, que pode ser disponibilizada aos consumidores sob demanda como servio compartilhado, sendo acessvel atravs de uma rede com localizao remota, onde cobrado uma assinatura ou pagamento pela quantidade de uso. O SaaS tem como caracterstica fornecer um aplicativo a vrios clientes e empresas de forma simultnea, utilizando a fundamentao de cauda longa, uma vez que, o objetivo SaaS fornecer o mesmo software para um maior nmero de clientes(contratantes) possveis. Para que os fornecedores possam distribuir SaaS ao invs de fornecer software pelo modelo tradicional, (CHONG & CARRARO, 2006) expem as mudanas quanto a forma do fornecedor (contratado) pensar, so elas: o modelo de negcios, a arquitetura do software e a estrutura operacional, estabelecendo um novo paradigma, uma vez que o provedor hospeda um aplicativo de modo centralizado e disponibiliza o acesso a vrios clientes pela Internet, em troca de uma taxa. No entanto, na prtica, as caractersticas marcantes entre um aplicativo instalado no local do cliente e um aplicativo SaaS no so as caractersticas binrias, e sim, trs distintas dimenses, sendo estas: como licenciado, onde est localizado e como gerenciado. O modelo SaaS est alterando a maneira como o software desenvolvido, consumido e entregue (em comparao s prticas de

desenvolvimento de software tradicionais), SaaS est provando ser uma tendncia divisora de TI. Uma das principais caractersticas que difere o desenvolvimento de um aplicativo SaaS e o de um aplicativo tradicional, que o aplicativo SaaS pode ser utilizado por diversos clientes. Outros requisitos fundamentais de um aplicativo SaaS so: segurana, customizao,

Arquitetura Orientada a Servios (SOA) e integrao, que esto relacionados diretamente na arquitetura SaaS (KOTHARI, 2011). A segurana de suma importncia na arquitetura do aplicativo SaaS, pois os dados e processos sero hospedados fora das instalaes de uma organizao. Em um modelo tradicional de implantao do aplicativo, os dados confidenciais de cada empresa continua a residir dentro dos limites da empresa e est sujeito sua segurana fsica, lgica e pessoal, assim como polticas de controle de acesso. No entanto, no modelo SaaS, os dados da empresa so armazenados fora dos limites da empresa, consequentemente, o fornecedor de SaaS deve adotar verificaes de segurana adicionais para garantir a segurana dos dados e evitar quebras, devido a vulnerabilidades de segurana no aplicativo ou atravs de funcionrios mal-intencionados, isto envolve o uso de tcnicas de criptografia fortes para garantir a segurana quanto ao controle de acesso aos dados (RANE, 2010).

1.1 OBJETIVO O objetivo deste trabalho oferecer um material de apoio sobre os conceitos que envolvem SaaS, referente sua arquitetura, organizao, vantagens/desvantagens, custo, aspectos tcnicos, segurana da plataforma e suas vulnerabilidades. Aps tais conceitos, sero mostrados subsdios para propor um modelo de gerenciamento de identidade.

1.2 JUSTIFICATIVA Os benefcios da utilizao de Software as a Service (SaaS) , que oferece solues de software entregues por meio do modelo de computao em nuvem , so claras para muitas organizaes e podem incluir significativa

economia de custo, produtividade e maior fora de trabalho. No entanto, a adoo desses servios tambm apresenta um grande desafio para os administradores de TI: o gerenciamento do controle de acesso. Na ausncia de um gerenciamento eficaz da identidade do usurio, acesso e credenciais (capacidade de controlar quem est usando o aplicativo e quando), as organizaes sofrem risco de comprometer a sua rede e segurana de dados. Eles tambm podem deixar de atender s demandas dos regulamentos de conformidade e o impedimento de uma investigao forense frente a um caso de perda de dados. Estas desvantagens podem minar os benefcios o do uso de solues SaaS. Paralelamente, diante do gradativo crescimento do nmero de aplicaes SaaS em uso nas empresas, a necessidade de uma fcil e eficaz maneira de administrar o acesso das solues SaaS traz consigo uma srie de solues de controle de gerenciamento. Somando-se ao desafio de controle de acesso, na empresa de hoje, as pessoas tm trabalhado em mais lugares fora da organizao, e com mais tipos de dispositivos para atender a vrias aplicaes e dados sensveis.

2 DEFINIO SOFTWARE AS A SERVICE SAAS

O SaaS um software distribudo como um servio e implementado em uma plataforma web, utilizando as tecnologias e protocolos, no necessitando de instalaes localmente (on-premise) e pago por demanda, tempo de uso ou volume. Pode-se dizer que o mesmo usa mecanismos de tarifao mtrica. Fornece uma API para acesso atravs de web services, interfaces REST, SOAP e/ou outros protocolos (CAMBIUCCI, 2009). O SaaS est inserido em dois contextos: o de linha de negcio em que o software distribudo em larga escala e vendido por assinatura, e os servios orientados a cliente que se d quando o software oferecido ao pblico gratuitamente (MOTA, 2009). Ainda de acordo com Motta (2009), o SaaS est mudando a forma do fornecedor pensar, uma vez que, oferece apenas o servio em vez de fornecer software na maneira tradicional, levantando questes de um novo modelo de negcio, arquitetura de software e estrutura operacional.

Figura 1 - Estrutura do modelo SaaS relao com modelo de negcio, arquitetura da aplicao e estrutura operacional. Fonte: Chong et al (2006)

Na Figura 1, vemos a relao da viso do fornecedor com a alterao do modelo de negcio, h mudanas de algumas caractersticas com relao ao modelo tradicional de software como: A propriedade do software do cliente para um fornecedor externo sofre significativas alteraes. Realocao da infraestrutura (parque tecnolgico) e gesto, ou seja, hardware e servios partem do cliente para o provedor. O uso da economia de escala reduz o custo da prestao de servio de software. Pequenas empresas podem reduzir o custo que o software pode ser vendido utilizando os conceitos de cauda longa.

Na relao arquitetura de aplicativo o objetivo que o cliente perceba que a utilizao de SaaS uma reduo de custo em potencial comparado ao modelo tradicional, ou quando pago pela assinatura do servio (RUSCHEL et al., 2010). Em um ambiente de TI tradicional onde os softwares so instalados localmente, o custo agregado ao hardware e aos profissionais, deixando apenas uma menor parte do investimento destinado a software como mostra na Figura 2.

Figura 2- Partilha de custos de ambiente tradicional de TI. Fonte: Chong & carraro (2006)

De forma mais detalhada, a Figura 2 retrata a diviso de custo em ambiente de TI tradicional, onde o custo agregado a hardware se d pelo gasto com o parque tecnolgico, servidores para hospedar dados, aplicativos e componente para coloc-los na rede. O custo de profissionais de servio, se d a equipe de suporte responsvel por implementar e realizar a manuteno do hardware e software, bem como, consultores e recurso de desenvolvimento para construir software personalizado, e a parte dos softwares que so as licenas. O modelo SaaS d a possibilidade de desdobramento na utilizao dos servios, onde o cliente pode ceder o software locado para uso de terceiros, aos quais iremos nome-los de usurios finais. Portanto, o cliente pode desenvolver diversas relaes de negcios com os usurios finais, podendo utilizar os meios de cobranas como: assinatura mensal ou anual, volumes de servios pela utilizao do software e servio disponibilizado gratuitamente. No servio disponibilizado gratuitamente o cliente busca outras formas de obter receita. Nessa modalidade, o cliente pode buscar parceiros ou cobrar por anncios, caso tenha um grande fluxo de usurios. Alm do custo inicial reduzido para o cliente, de acordo com Chong & Carraro (2006), h uma porcentagem maior da receita disponvel para gastar em software, normalmente na forma de taxas de assinaturas, transaes, ou por meio de anncios. Por fim, a estrutura operacional tambm alterada. Geralmente, o investimento com Tecnologia da Informao (TI) nas organizaes gasto em trs reas distintas como j foram transcritas acima que so: software, hardware e servios profissionais (BLOKIDIJK, 2008). Segundo Mota (2009), o software o que geralmente est mais envolvido no gerenciamento das informaes, porm, em modelo de software local, a maior parte do investimento gasto em hardware e servios profissionais, ficando a outra parte disponvel para software. A figura 3 apresenta a alocao de recursos em um ambiente SaaS.

Figura 3 - Diviso tpica de investimento em ambientes SaaS. Fonte: Chong & Carraro (2006)

Na Figura 3, o fornecedor de SaaS hospeda aplicativos crticos e dados associados em servidores centrais, o suporte ao hardware e software feito atravs de uma equipe de suporte dedicada, aliviando a organizao do cliente e a responsabilidade de apoiar o software hospedado, para a aquisio e manuteno de hardware e servidor . Alm disso, os aplicativos so entregues pela Web ou por meio de clientes com uma demanda significativamente menor do que um computador desktop, ou de um tradicional aplicativo instalado localmente, o que permite ao cliente estender o ciclo de vida da tecnologia de desktop de forma significativa. O resultado final que uma porcentagem muito maior do oramento de TI so disponvel para gastar em software, na forma de taxas de inscrio para os fornecedores de SaaS (CHONG &CARRARO, 2006). 2.1 CONCEITOS DE SOFTWARE COMO SERVIO Segundo SIIA (2001), o software como um modelo de servio capaz de causar uma mudana na indstria de software. No entanto, Software as a Service ainda deve superar vrios obstculos significativos adaptao generalizada. O primeiro entre tais obstculos pode ser a falta de clareza na definio dos prprios servios de software. O mercado dificultado por divergncias sobre as caractersticas intrnsecas dos servios e at mesmo a terminologia usada para descrever servios de aplicativos. As definies esto

constantemente mudando, fustigada pela criao de novos modelos de negcios e tecnologias que as empresas utilizam para entregar a sua viso do software como um servio. O mercado inundado com siglas cada um representando uma abordagem um pouco diferente - de servios provedor de aplicao (ASP), os provedores de infraestrutura de aplicaes (AIP), de servios de Internet de negcios (IBS), servios provedor de negcios (BSP), prestador de servios de solues (SSP), entre outros. Portanto, para evitar confuso, SIIA (2001) se refere ao modelo geral de software como servio.

No software como um modelo de servio, o aplicativo ou servio implantado a partir de um centro de dados centralizados atravs de uma rede - Internet, Intranet, LAN ou VPN de acesso e uso em uma base com taxa de retorno. Os usurios podem "alugar", "assinar", "atribuir", ou "ter acesso a", as aplicaes de um provedor central (CARRARO & CHONG, 2007). Os modelos de negcio variam de acordo com o nvel de simplificao do software, o baixo preo e o aumento da eficincia ou do valor acrescentado atravs das personalizaes para melhorar os processos de negcio digital. O valor fundamental de software como servio est no fornecimento do acesso e manejo, disponvel comercialmente atravs de aplicaes. Os benefcios potenciais do modelo so significativos tanto para o vendedor quanto para o cliente. Este servio diferente de Business Process Outsourcing (BPO), por exemplo, em que o contrato de terceirizao abrange a gesto de processos de negcios.

O Software as a Service (SaaS), tornou-se uma ferramenta significativa para as indstrias de software, j que a mesma tida como um modelo de negcio que centraliza e organiza informaes, utilizando a internet e por custos menores quando comparado com softwares tradicionais (MOTA, 2009).

Segundo Cox (2010), o Software as a Service se define como um servio hospedado e disponvel pela internet e pode ser classificado em servio orientado a cliente e servio de linha de negcio, em que um software distribudo em larga escala e vendido por assinatura, j o outro software oferecido ao pblico gratuitamente e custeado por anncios. Mas, h algumas divergncias no contexto do uso da internet para a utilizao desse modelo, assim, a anlise de algumas grandes empresas como a IBM e a MICROSOFT mostra conceitos diferenciados. De acordo com Melo et al. (2007), a IBM afirma que o uso da internet apenas direcionado para a transferncia dos bits, e representa o servio, no entanto, no utilizada de forma obrigatria, j a Microsoft afirma que a internet para este modelo indispensvel.

2.2

ANLISE DE CUSTO
A simples utilizao de SaaS para a distribuio de servio na web no o motivo primordial para a sua adoo, para tal implementao h vrias estratgias econmicas para garantir a receita e estudos de custos com estimativas de uso das funcionalidades, que esto sendo oferecidas pelo servio (Greer, 2009).

SaaS elimina a necessidade de cada empresa para comprar, implantar e manter infraestrutura de TI ou aplicativo de software. No modelo SaaS, o fornecedor assume a responsabilidade para implantar e gerenciar a infraestrutura (servidores, software de sistema operacional, banco de dados, espao no data center, acesso rede, energia ,refrigerao, etc.) e processos (manchas de infraestrutura / upgrades, correes de aplicativos / upgrades, backups, etc.) necessrias para executarem e gerenciarem a soluo completa. Porque os fornecedores de SaaS gerencia todos os seus clientes em uma nica instncia do software, que podem amortizar os custos relacionados com infraestrutura para milhares de clientes. Isso gera economias substanciais de escala e habilidade, e reduz o custo total de propriedade (TCO - Total Cost of Ownership).(CHONG & CARRARO, 2006)

10

A Figura 4 mostra um estudo da empresa Brivo (www.brivo.com) transcrito em um artigo de 2009, em que a mesma demonstra que uma soluo SaaS pode ter um custo na faixa de 76% (setenta e seis por cento) menor que uma soluo baseada em servidor.

Figura 4 - SaaS vantagem de custo sobre servidor baseado em sistemas tradicionais. Fonte: Brivo, 2009

Adicionalmente, Figura 4 mostra a vantagem de custo relativo da soluo SaaS ao longo de um tradicional sistema baseado em servidor. A primeira coluna ( esquerda) mostra o TCO de cinco anos de uma soluo SaaS. A coluna seguinte (em vermelho) mostra a despesa acumulada mensal das taxas de SaaS, em comparao com um servidor instalado. No entanto, este pequeno dficit rapidamente compensado pelas prximas trs colunas, que representam as despesas com as categorias que so suportadas apenas pela soluo de servidor. No efeito lquido, estas categorias somam um TCO muito maior para o sistema baseado em servidor. Nota-se que as economias de SaaS so alcanados sem levar em conta a despesa ou impacto nos negcios de inatividade do servidor, que pode ser considervel para muitos tipos de empresas. Quando estes fatores de

11

custos adicionais so inseridos, a eficcia do custo de soluo SaaS ainda mais dramtica (BRIVO, 2009). Na Figura 5 vemos com mais visibilidade a relao do custo de despesas de implantao de um sistemas baseado em servidor com relao a uma implantao SaaS.

Figura 5 - Analise de custo instalao de sistemas baseado em servidor e SaaS. Fonte: Brivo, 2006

Contudo, a diferena de custo entre implementaes de sistemas baseados em servidores bem significativa em relao soluo SaaS. Entretanto, a soluo deve estar inserida no quadro de anlise a longo prazo, para que tal economia seja verdadeira. Por este motivo, no prximo tpico ser analisada a teoria da calda longa.

2.3

CONCEITO CAUDA LONGA APLICADA SAAS

O conceito de SaaS nos leva ao entendimento que o mesmo se refere ao uso do software disponvel pela web para vrios usurios e empresas ao mesmo tempo, gerando assim, uma economia de escala, onde uma empresa fornece um pequeno nmero de produtos para uma maior quantidade possvel de consumidores (ANDERSON,2006).

12

Ao eliminar grande parte da manuteno, e utilizando a economia de escala para combinar e centralizar hardware dos clientes e os requisitos de servios, fornecedores de SaaS podem oferecer solues a um custo muito menor do que os fornecedores tradicionais, no s em termos monetrios, mas tambm reduzindo a necessidade de clientes para adicionar complexidade sua infraestrutura de TI. Isso permite ao SaaS acesso exclusivo a uma gama inteiramente nova de clientes em potencial, que sempre esteve inacessvel aos fornecedores de solues tradicionais, porque nunca foi rentvel para servi-los (CHONG & CARRARO, 2006). Os fornecedores de soluo SaaS, se defrontam com uma curva de negcio bem semelhante ao da cauda longa, tal conceito implica na procura elevada de um conjunto pequeno de produtos e procura muito reduzida para um conjunto elevado de produtos. Em uma economia tradicional, os custos fixos de manuteno de estoques, permitem calcular um valor para a procura que define a fronteira entre lucro e prejuzo (WITHINK, 2008, on line). No caso dos novos parmetros da economia, este pensamento colocado sobre questionamento, muito particularmente no caso dos produtos digitais. Por exemplo, o custo de manuteno de um produto muito procurado igual ao custo de manuteno de um produto procurado apenas por um nmero mnimo de consumidores. Ainda o site Wething (2008) afirma que, apostar na cauda Longa, tornase economicamente interessante, pois conforme baixo custo de adoo, um nmero maior de clientes pode adotar tal soluo. E esse nmero tende ao infinito, uma vez que a curva no toca o eixo x (Figura 6). Assim, no modelo SaaS de fornecimento de software, necessrio pensar em solues e infraestrutura de baixo custo, com alto aproveitamento de recursos por um nmero muito grande de clientes, para se atingir um pblico no suportado hoje em dia devido os custos proibitivos de entrada.

13

Figura 6 - conceito de calda longa. Fonte: Anderson (2006).

2.4

SLA - SERVICE LEVEL AGREEMENTS Segundo a UnicommKnowledged (http://www.uni.com.br), uma

empresa para a rea de gesto empresarial e tecnologia da informao, os contratos de TI mal elaborados proporcionam a maioria dos problemas nos projetos de terceirizao. A mesma ainda define que de suma importncia a existncia de uma definio compreensvel dos termos contratuais, que possua um detalhamento completo dos servios e produtos que esto sendo oferecidos, limites de atuao, formas de proteo, clara definio de abrangncia, entre outros aspectos. Contratos como os da soluo SaaS podem deixar as bases de contratao a desejar, se no houver uma anlise minuciosa de todos os aspectos para a sua elaborao. A consequncia que os objetivos esperados no podem ser garantidos apenas por si mesmos, tendo de deixar de lado

14

fatores primordiais como a frmula de composio, distribuio dos servios e todas as suas vantagens. A confeco de um contrato adequado garante as suas funcionalidades e a concretizao dos objetivos estratgicos que podem estar relacionados adoo destes modelos de software Os contratos de TI, mais conhecidos como Service Level Agreement (SLA), que Mota & Palmas (2006) definem que o mesmo um acordo entre o fornecedor de servios e um cliente sobre nvel de servios, em que o fornecedor se compromete a ressarcir o cliente pelo tempo em que a aplicao no estiver disponvel. O SLA define parmetros de negcios e/ou de suporte tcnico que um provedor de servio fornecer a seu cliente, especificando medidas de performance e consequncias por no atingir as netas ou falhas

Um contrato SLA define as responsabilidades que implicam entre o provedor (contratado) e a empresa responsvel pela contratao, delimitando assim as devidas responsabilidades de ambas as partes, dentre essas incluem: funes repetitivas, definies, processos e tambm produtos que sero criados e entregues. Est inserida neste conjunto de acordos a delimitao de cada etapa do servio, e suas restries (PEDRO, 2009).

Alm do conjunto de acordos que so inseridos no contrato SLA, de grande importncia que sejam utilizadas ferramentas que auxiliem durante o processo de gerenciamento. Quando os servios forem definidos e o contrato estiver de acordo para ambas as partes (contratado e contratante), o documento SLA fica sob posse de ambos, para que sejam gerenciados os fluxos de servios. O gerenciamento das aplicaes cliente-servidor em operao fica sob a responsabilidade do contratante que est com a posse da licena do software, diferindo da soluo SaaS em que o problema estritamente da contratada que fornece o servio. Porm, existe tambm a possibilidade de terceirizar o servio, solicitando um Data Center ou subcontratando um profissional especializado, responsabilizando este com multas, se o contrato no for devidamente cumprido na ntegra, aponta Mota (2009).

15

2.5

VANTAGENS E DESVANTAGENS

O sistema SaaS tem como uma de suas vantagens ser projetado para prover confiabilidade de acesso, segurana dos dados, dentre outros, e tambm responsvel por promover a funcionalidade do servio que em algumas situaes tem que suportar e manipular uma grande demanda de dados e continuar gerando respostas rpidas. Para que haja eficcia neste software necessrio o acoplamento com mo de obra, novas tecnologias, dentre outros. Quando o cliente utiliza as solues tradicionais (baseada em cliente-servidor) se depara com custos bastante elevados, diferente da soluo SaaS, uma vez que o prprio fornecedor do servio se responsabiliza pela manuteno do software para o contratante, no sendo necessrio

preocupao com custos elevados com o servio, de acordo com Pedro et al. (2009). Borges (2010) afirma que de fundamental importncia que qualquer software comercial garanta a segurana durante a transmisso de dados. Contudo, quando utilizamos a soluo SaaS encontramos algumas

desvantagens. Segundo Rane (2010), uma destas desvantagens encontrada no modelo SaaS est relacionada a internet, que um ambiente compartilhado, o que a diferencia do ambiente tradicional, alm do fato de que todos os dados trafegam por essa rede. J que esse conjunto compartilhado, como deve ser garantida a segurana desses dados para que no ocorra invaso ou acesso do contedo pelo concorrente ou pessoas no autorizadas? Para garantir a eficincia na segurana da transmisso dos dados pela internet, realizada a soluo criptografia em nveis elevados. Essa, por sua vez, se d por meio de chaves criptogrficas que trabalham por meio de mtodos pblicos e privados. Rane (2010), ainda afirma que quando a soluo SaaS projetada para comercializao, deve garantir ao cliente a confiabilidade dos dados, j que esse software nico para todos os usurios. Porm as informaes de cada usurio so utilizadas de forma particular e individualizada. Para haver uma segurana maior neste software os dados que trafegarem na rede deve utilizar chaves criptogrficas a partir de 64bits, afinal, as inferiores no

16

garantem a confiabilidade das informaes devido fragilidade e facilidade de quebras dos protocolos de criptografia.
Outra desvantagem esta na migrao do contedo (dados). Se o contratante, por exemplo, resolver mudar de contratado por qualquer motivo relevante que seja, dever exigir a transferncia dos seus dados, e o contratado dever assegurar ao contratante a liberdade de migrao do contedo para um formato externo, assim como a funcionalidade dos dados para outra aplicao, no momento que o contratante julgar necessrio. Quando o aplicativo bem gerenciado no h problema durante a exportao desses dados. Porm, a dificuldade pode ser observada tambm de uma maneira diferente. O contratado pode, por exemplo, desenvolver uma soluo de servio que oferea ao contratante a possibilidade de em algum momento compartilhar informaes com outras aplicaes, assim como um software que permita uma maior combinao com as aplicaes do contratante, esse servio do contratado ser de interesse do contratante, ganhando um destaque diferencial em relao aos servios do concorrente. (MOTA,2009)

2.6

SAAS VERTICAL E HORIZONTAL De acordo com Chong & Carraro (2006), SaaS est classificado em

duas categorias: servios de linha de negcios e servios orientados a cliente. Os servios de linha de negcios, conhecidos como software vertical, so fornecidos s empresas e organizaes de todo tipo. Os softwares verticais so aplicaes que contm conhecimentos de uma ou mais especialidades. A venda feita sob a forma de encomendas e geralmente so comercializados a setores especficos. So aplicativos de interesses grandes e personalizveis com o intuito de facilitar processos de negcios. J o software horizontal de uso geral, a distribuio geralmente feita em larga escala e a preferncia dos consumidores se d pela marca e reputao das empresas. Ou seja, esses softwares servem para qualquer segmento de mercado. O software horizontal tambm conhecido com servios orientados cliente um servio oferecido a todos os meios. Esse tipo normalmente vendido sem custo e financiado por anncios.

17

2.7

SAAS CORPORATIVO Os softwares corporativos so utilizados exclusivamente pelas

empresas. A maioria das organizaes sente a falta de algumas informaes que no so integradas com outros aplicativos da empresa, o que torna difcil a localizao de tais dados. Na atualidade, a web se tornou um meio eficaz para o fornecimento de informaes. A grande maioria das organizaes busca obter maior eficincia operacional de seus dados, indo de encontro tendncia de alterar o local da utilizao dos softwares. O aparecimento da soluo SaaS trouxe melhores oportunidades para o negcio em geral. Quando uma empresa torna-se um provedor de SaaS a mesma pode disponibilizar aplicativos personalizados aos seus clientes, tais como controle de estoque, contabilidade, bancrio, entre outros. uma vantagem para as empresas oferecerem esses servios a outras empresas, principalmente se o software desenvolvido for de qualidade. Segundo Chong & Carraro. (2006), os princpios que permitem empresa utilizar os benefcios da Cloud tambm admitem oferecer servios mesma. De acordo com Wething (2008), um software do tipo coorporativo distribudo como SaaS representa servio de integrao significativa". Ou seja, a integrao dos dados no deixa de ser um servio complexo para incorporar os dados ao SaaS. Acredita-se que o futuro do software corporativo no se apoiar simplesmente em recursos instalados na mquina local ou na internet, existindo, assim, uma relao de integrao entre ambas.

18

3 ARQUITETURA SAAS
Vrios tipos de componentes de softwares, aplicaes e frameworks podem ser aplicadas no modelo de desenvolvimento SaaS. O aparecimento de componentes e aplicaes modernas e novas tecnologias reduz drasticamente o tempo hbil de mercado e os valores agregados para a converso de um produto do modelo tradicional em uma soluo SaaS. Segundo Rittinghouse (2010), a arquitetura SaaS classificada em 04 (quatro) nveis de maturidade em que os atributos chaves podem ser configurados. Estes nveis so: Maturidade da Arquitetura Nvel 1 Ad-hoc/custom: cada cliente possui uma nica e customizada verso do aplicativo de hospedagem. O aplicativo roda no servidor de hospedagem. Migrar um aplicativo tradicional ou um cliente-servidor para este nvel de SaaS requer maturidade para mais um esforo de desenvolvimento, reduzindo custos operacionais por consolidar o servidor de hardware e administrao. Motta (2009) defende que nesta etapa o atendimento do cliente diferenciado e o software individualizado, porm, o custo com este servio bastante alto, pois cada usurio, de forma particular, utiliza o aplicativo hospedado em sua verso personalizada, e utiliza no aplicativo a solicitao nos servidores do host. Maturidade da Arquitetura Nvel 2 Configurabilidade: o segundo nvel de maturidade SaaS fornece uma maior flexibilidade de programa por meio da configurao meta data. Neste nvel, muitos clientes podem usar separadas instncias para a mesma aplicao, permitindo que o vendedor possa ter vrias opes de configurao a partir das necessidades dos clientes. Alm disso, permite que o vendedor alivie a carga de manuteno por ser capaz de fazer atualizaes com base em um cdigo comum.

19

Maturidade da Arquitetura Nvel 3 Eficincia Multilocatria: o terceiro nvel adiciona o carter de locao mltipla ao segundo nvel. Isto resulta em um simples programa que tem como exemplo a capacidade de servir a todos os clientes. Esta abordagem permite maior eficincia no uso de recursos, sem que haja qualquer diferena aparente para o usurio final. Entretanto, ultimamente este nvel limitado em um escala massiva. Maturidade da Arquitetura Nvel 4 Escalabilidade: a escalabilidade adicionada pelo o uso de uma arquitetura em multicamadas. Esta arquitetura capaz de suportar uma carga de explorao equilibrada, por exemplo, aplicaes idnticas rodando em um nmero grande de servidores (centenas ou milhares). A capacidade do sistema pode ser dinamicamente acrescida ou reduzida para equacionar a demanda de carga/carregamento, adicionando ou removendo servidores, sem a necessidade de alterar a arquitetura dos aplicativos e softwares.

Os nveis que presenciamos de maturidade neste estudo so caractersticas importantes do modelo SaaS, trazendo o pensamento de que o nvel mais apropriado de maturidade seja o ltimo. Porm, deve-se levar em considerao que o processo de maturidade acontece atravs de uma sequncia contnua, em que de um lado se d os cdigos e os dados separadamente e do outro lado dados e cdigos compartilhados. Na prxima seo ser visto o ciclo de desenvolvimento SaaS, passando por todos os seus processos, desde os conceito de multiusurio (multi-tenant) at o ciclo de vida do desenvolvimento.

3.1

CICLO DE DESENVOLVIMENTO As aplicaes SaaS que so disponibilizadas para os clientes do

servio so aplicaes de software que um fornecedor SaaS desenvolveu, de acordo com padres especficos (incluindo protocolo de rede, servio,

20

protocolo, segurana, transporte, etc.). Estes softwares podem ser publicados em um servidor na Internet. Alm disso, o usurio no precisa adquirir o certificado do software, apenas alugar o mdulo de funo do software, de acordo com a demanda fsica prpria, e pagar de acordo com o tipo de servio, nmero e tempo de uso. Conforme estas caractersticas, o quadro dos aplicativos SaaS deve ter estruturas como servio de camada de transporte, servio de camada de programao, camadas de tecnologias de servios, camadas de servios e dados, e servios da camada de gesto, afirma He (2010). Na prximas linhas ser descrito um estudo mais especfico. Servio de camada de transporte: garante o retorno da informao sobre a exatido de solicitaes de usurios e aplicaes, atravs do uso de SOAP, Web Service, XML e alguns protocolos correspondentes de rede e segurana. Servio de camada de programao: possibilita o usurio escolher o servio que a plataforma oferece, de acordo com o prprio pedido. Nesta instncia o cliente pode parametrizar a aplicao, definir os campos, a forma do menu, o fluxo de trabalho, as propriedades, entre outros. Camadas de tecnologias de servios: tal camada tem como funo, manter o contato do cliente com o fornecedor da aplicao, ou o prestador de servio, para assim, se dar as negociaes do tipo de servio, lanamentos dos servios, integrao e etc. Esta camada fornece servio API (Application Programming Interface) ou web. Camadas de servios e dados: fornece API e servio web especial para a transferncia de formao superior (pequenas, mdias ou grandes empresas). Ele implementado pelo pacote de processos bsicos de acordo com o resumo da demanda do mercado. Portanto, esta camada expressa a diferena entre os tipos de aplicaes SaaS, como SBM, CRM, RH ou ERP, entre outras.

21

Servios da camada de gesto: oferece trs maneiras de gerenciar dados de mltiplos usurios, bancos de dados independentes, banco de dados compartilhado e isolamento de esquema de dados, banco de dados compartilhado e estruturas de dados compartilhados.

De acordo com He (2010), um projeto de desenvolvimento SaaS para ser considerado ideal precisa atender trs caractersticas: cliente construdo, elasticidade e multiusurios eficientes. O conceito de elasticidade se d quando uma alocao de recursos pode ser maior ou menor, dependendo da demanda. A elasticidade garante a escalabilidade, o que significa que o SaaS pode ser escalado ascendentemente para demandas de pico, e descendentemente para demandas mais leves. Escalabilidade tambm significa que um aplicativo pode ser escalado quando so adicionados novos usurios e quando os requisitos do aplicativo mudam. O modo de desenvolvimento SaaS de multiusurio eficiente possui diferenas significativas com relao ao desenvolvimento tradicional de softwares, dividido em duas partes: isolamento de dados e implementao da interface. O autor ainda afirma que os dados para aplicao de um nico usurio legado so fixados sobre a mesma base de dados, sem os problemas que envolvem o isolamento dos dados. H trs modelos de SaaS que controlam o armazenamento dos dados: banco de dados separados, banco de dados compartilhados (esquema separado) e banco de dados compartilhado (esquema compartilhado). Abaixo a descrio dos bancos: Banco de dados separados: segundo Wolter et al. (2006), geralmente todos os inquilinos compartilham os recursos da mquina (e da aplicao) de um mesmo servidor, mas as informaes de cada

inquilino so diferentes, e permanecem isoladas dos dados pertencentes a outros inquilinos. Os metadados recebem a incumbncia de fazer as associaes corretas dos bancos de dados para os seus respectivos inquilinos. Quem responsvel por garantir a integridade das informaes para que os inquilinos no acessem os dados de outros so a prerrogativas de gerenciamento de segurana do fornecedor SaaS. A

22

Figura 7 apresenta a abordagem dos bancos de dados separados, ilustrando os dados dos inquilinos.

Figura 7 - Abordagem usando um banco de dados distinto para cada inquilino. Fonte: Wolter et al. (2006).

Banco de dados compartilhado (esquema separado): Wolter et al.(2006) ainda demonstra o armazenamento das informaes de mltiplos inquilinos numa mesma base de dados, em que os inquilinos iro possuir um conjunto de tabelas, que sero agrupadas em um esquema especifico para cada inquilino, conforme mostra a Figura 8.

23

Figura 8 - Abordagem em que cada inquilino possui seu prprio conjunto de tabelas numa mesma base de dados. Fonte: Wolter et al.(2006).

O complemento do desenvolvimento do modelo SaaS se d com a implementao da interface. Segundo He (2009), em uma aplicao tradicional a interface do sistema sempre atende aos requisitos bsicos para o usurio, pois a interface feita sob medida e implantada de acordo com a exigncia do usurio. No modelo SaaS as aplicaes utilizam o mesmo conjunto de interface, no podendo atender todas as necessidades dos usurios. Assim, os recursos configurveis das interfaces das aplicaes SaaS no podem ser ignorados. A pgina pode ser dividida em menu do sistema e os elementos da pgina, em que ambos devem ser dispostos a receber personalizao de seus clientes. O modelo SaaS tambm possui um ciclo de vida para a estrutura de desenvolvimento. A Figura 9 mostra o ciclo de vida de desenvolvimento do modelo SaaS, apontando o que as novas solues partilham no momento de definio de qual tipo de aplicativo ser desenvolvido para o fornecimento do servio que ser proposto para o usurio final.

24

Figura 9 - Ciclo de vida do desenvolvimento SaaS. Fonte: Kommalapati & Zack (2011).

Segundo Kommalapati & Zack (2011), o ciclo de vida para o desenvolvimento apresenta seis nveis: prevendo, avaliao da plataforma, planejamento, inscrevendo, desenvolvimento e operaes. Estes nveis descrevem as melhores prticas no momento da deciso da criao de um novo aplicativo para o fornecimento de servio. Nas prximas linhas mais detalhes sero abordados.

1. Prevendo: nesta fase do desenvolvimento o fornecedor procura identificar as novas tendncias e as oportunidades de negcio com o objetivo de sempre expandir a quantidade de clientes para chegar ao conceito de cauda longa, definindo, assim, as vises e o escopo do servio SaaS.

2. Avaliao da plataforma: nesta etapa ocorre a escolha do provedor da nuvem, momento caracterizado pelos autores Kommalapati & Zack

25

(2011) como crtico para o sucesso da aplicao, uma vez que o provedor pode influenciar no nvel 1 (um), se o provedor de nuvem no possuir as caractersticas necessrias para alocar o tipo de servio definida na primeira fase, toda a arquitetura do servio dever se adaptar ao provedor.

3. Planejamento: aps identificao plataforma de nuvem vivel para a construo do servio de SaaS, a fase de planejamento ajudar a traar o curso de ao para uma entrega previsvel do servio. Planejamento depende muito do tipo de servio e da cultura organizacional. O rigor das atividades e os resultados finais dependem da complexidade e do tamanho do servio. As atividades nesta fase so muito semelhantes aos do ciclo de vida tradicional de desenvolvimento de software.

4. Inscrevendo: nesta etapa o provedor de nuvem submetido a exames mais impulsionados pelas necessidades de produo, implantao e operacionais do servio que est sendo planejado. Os arquitetos e profissionais de TI iro revisitar os modelos de implantao, esquemas, modernizao, processos de apoio, continuidade de negcios e recuperao de desastres.

5. Desenvolvimento: ocorre atravs da construo dos artefatos e elaborao da documentao, podendo o projeto sofrer alteraes a partir da descoberta de novas funcionalidades e da alocao de recursos. O escopo de funcionalidade e o cronograma determinam a granularidade e nmero de interaes.

6. Operaes: nesta etapa acontece o processo de implementao do aplicativo, integrao e personalizao dos aspectos operacionais da plataforma no contexto do servio implantado.

O ciclo de vida para o desenvolvimento SaaS utiliza algumas premissas do modelo do ciclo de desenvolvimento de aplicativos baseados em

26

servidores, assim, Motta (2009) questiona o gerenciamento de tal ciclo de vida de desenvolvimento afirmando da seguinte maneira:
Em relao ao fator gerenciamento do ciclo de vida da aplicao, as empresas precisam desenvolver mais o setor de gerenciamento da informao para manter e operar as aplicaes de SaaS. Precisam conhecer o ambiente do cliente, prezar pelas aes operacionais no sentido de resolver problemas de segurana, performance, disponibilidade, entre outros. O objetivo que realmente os fornecedores de SaaS cuidem da gerncia de TI, pois a empresa no possui mais a aplicao.

As prximas sees comentaro sobre a segurana no ambiente SaaS.

3.2

SEGURANA SAAS Segundo Motta (2009), um dos maiores desafios para os fornecedores

de SaaS a fabricao de sistemas que possuam mais segurana, que necessite de menos atualizaes e possam permitir um gerenciamento de segurana com problemas reduzidos. Os autores Rittinghouse & Ransome (2010) transcrevem 07 (sete) questes de segurana para a discusso direta com os fornecedores de Cloud Computing e SaaS. Esta questes foram enumeradas por analistas da empresa Gartner (http://www.gartner.com), sendo abordadas nas prximas linhas:

1. Acesso privilegiado: o autores apontam os tipos de argumentaes que devem ser realizadas ao fornecedor com relao a quem possui acesso especializado aos dados, assim como as possveis contrataes de administradores.

2. Conformidade com as regulamentaes: o autores enfatizam que o cliente deve certificar que o fornecedor estar disposto a se submeter a auditorias externas e possuir certificaes de segurana.

27

3. Localizao dos dados: o cliente deve questionar se o fornecedor permite controles sobre a localizao dos dados.

4. Segregao dos Dados: o cliente deve questionar ao fornecedor SaaS se a criptografia est presente em todas as etapas da comunicao, e se tal funcionalidade foi testada e implementada por profissionais confiveis.

5. Recuperao dos dados: o cliente deve questionar sobre a recuperao dos dados, caso ocorra possveis eventualidades,

catstrofe, e em quanto tempo o fornecedor disponibilizar os dados de volta.

6. Apoio Florence: o cliente deve questionar se o fornecedor possui, mtodos para ajudar em uma possvel investigao.

7. Viabilidade em longo prazo: o cliente deve questionar ao fornecedor sobre suas polticas de entrega dos dados caso a empresa venha a sair do ramo de negcio, assim tambm como qual tipo de formato tais dados sero entregues.

Vrios outros autores falam sobre estudos de grandes empresas no ramos de segurana para a plataforma SaaS, Brodkin (2010) cita em seu artigo a empresa Forrester (http://www.forrester.com), em que um de seus analistas, Liz Hebert, escreveu sobre alguns equvocos que acontecem na adoo da soluo SaaS, tais como gerenciamento imaturo de identidade, a

inconsistncia nos padres de cloud, sigilo, a grande disponibilidade de acesso, que traz o aumento de riscos, e a localizao difusa dos dados. Todos estes estudos encontrados no decorrer da pesquisa levam a visualizar a inconsistncia do modelo, mostrando, assim, a necessidade cada vez maior da implementao de um gerenciamento consistente. O capitulo 3 abordar as vulnerabilidades e riscos que assolam o modelo SaaS.

28

3.3

GESTO DE RISCOS SAAS Segundo Ramos (2007) em um artigo para web, a gerncia de riscos

um processo que deve ser executado continuamente e seus gestores tm responsabilidade direta na conduo do processo. Ramos ainda afirma que a gerncia do risco se divide quatro partes: identificar e avaliar os riscos, tratar os riscos, aceitar os riscos abaixo da linha de corte e comunicar os riscos. Uma gesto eficaz dos riscos na plataforma SaaS implica na identificao de ativos de tecnologia, identificao de dados e suas ligaes com os processos de negcio, aplicaes e dados e a atribuio de propriedade e responsabilidades privativas de liberdade. As aes devem

incluir a manuteno de um repositrio de ativos. Os proprietrios tm autoridade e responsabilidade para os ativos de informao, incluindo os requisitos de proteo, como confidencialidade, integridade, disponibilidade e controles de privacidade. Um processo formal de avaliao de risco deve ser criado e os recursos de segurana ligados continuidade dos negcios. Gruman & Pita. (2007) tambm afirmam que os clientes devem exigir dos fornecedores de SaaS os mesmos requisitos de auditoria e controle que exigiriam de qualquer terceiro, incluindo clusulas de segurana para garantir privacidade dos dados, direitos sobre o software e sobre os dados, caso o fornecedor saia da atividade.

3.4

VULNERABILIDADES SAAS

SaaS

envolve

diferentes

atores,

nomeadamente

clientes

fornecedores. O primeiro usa o servio de aplicao previsto por este ltimo. Cliente SaaS geralmente usa um multi-level (multi-lateral) modelo de segurana para acessar remotamente o servio, por exemplo, uma empresa ter diferentes usurios que acessam o software com privilgios diferentes. Um servio de SaaS pode ser oferecido a um nico cliente, mas muitas vezes projetado com uma arquitetura multi-tenant, em que o mesmo servio oferecido para vrios clientes. Embora algumas aplicaes SaaS paream um

29

pedao monoltico de software para o cliente, ele pode realmente ser implementado com uma arquitetura multi-fornecedor. O fornecedor poder hospedar seus aplicativos em seu prprio Data Center, ou, simplesmente, explorar os recursos de outros. Por exemplo, um fornecedor poderia usar recursos de hardware de terceiros e, portanto, ao estudar a segurana de um Servio SaaS, deve-se considerar quatro tipos de ameaa: a interao clientefornecedor, as internalizaes cruzadas entre diferentes clientes para o mesmo fornecedor, a interao entre o provedor de SaaS e os sub fornecedores e, finalmente, atacantes externos que podem segmentar qualquer parte da soluo SaaS. Assim, neste tpico se estudar as vulnerabilidades e as classificaes da seguinte maneira: mau comportamento do servio,

computao confivel, violao dos dados dos clientes, compartilhamento de recursos, ameaas a rede e autenticao.

3.5

MAU COMPORTAMENTO DO SERVIO

Um provedor pode adulterar dados, aes ou eventos relacionados execuo de aplicativo SaaS para esconder violaes das condies contratuais. Como por exemplo, um provedor pode criar arquivos de log ou adulterar os sistemas de auditoria para esconder violaes de SLA, QoS ou acordos que foram feitos isoladamente, com intuito de prejudicar diretamente o servio e o contratante.

3.6

COMPUTAO CONFIVEL

Segundo artigo escrito por Brodkin (2010) para a revista NetworkWorld (http://www.networkworld.com), os fornecedores de SaaS tendem a argumentar que eles so mais capazes de proteger os dados que um tpico cliente, e que a segurana SaaS realmente melhor do que a maioria das pessoas pensam. Mas na realidade os clientes no se deixam levar sobre esta afirmativa porque

30

os fornecedores de SaaS tendem a ser bastante reservados sobre seus processos de segurana. O autor ainda afirma que muitos dos prestadores de servios em nuvem liberaram poucos detalhes sobre seus centros de dados e operaes, alegando que comprometeria a segurana. Um contratado (provedores) pode prestar servio no confiveis para o cliente utilizando de preceitos mal-intencionados. Alm disso, um provedor pode realizar aes no autorizadas/solicitadas representando clientes. Por exemplo, pensando em um servio que pode fornecer e comercializar informaes, o provedor poderia conspirar com outro cliente e modificar o servio para tornar os resultados falsificados, ou apenas um subconjunto dos resultados corretos para beneficiar tal cliente. Um cenrio semelhante poderia envolver um servio que executa elaboraes teis para a anlise de prottipo, assim, o provedor poderia modificar o servio de forma aleatria tornando os resultados errados para atrasar o processo de desenvolvimento de um cliente. Dadas essas ameaas, a soluo SaaS deve esta equipada com funes que verifiquem integridade, alerta Agrawal et al. (2011).

3.7

VIOLAO DOS DADOS DOS CLIENTES

Um contratado (provedor) pode executar aes enquanto os dados de uma aplicao so acessados ou armazenados. As possveis ameaas que atuam nesta etapa so de leituras no autorizadas e as modificaes dos dados podem forjar informaes e at mesmo exclu-las, trazendo, assim, uma alta responsabilidade para tais contratados (provedores). Um usurio malintencionado pode usar as vulnerabilidades de aplicativos para artesanato, com parmetros que ignoram as verificaes de segurana e acessam dados confidenciais de outros inquilinos. Intruso especfica pode levar a segregao de dados do fornecedor de uma soluo SaaS em uma implantao de multitenant.

31

Nozaki et al. (2010) afirma que qualquer uma das vulnerabilidades listadas abaixo podem ser exploradas para obter acesso a dados corporativos confidenciais de outros inquilinos. Falhas de Injeo SQL A validao de dados Armazenamento inseguro

3.8

COMPARTILHAMENTO DE RECURSOS

A soluo SaaS possui alguns recursos que so compartilhados entre vrios clientes, tais recursos podem ser apenas de hardware (em

implementaes baseadas em virtualizao), bem como a distribuio de servios de armazenamento, multiusurio de software, e at mesmo processos de aplicao (quando aplicado em um paradigma multi-tenant). Os dados dos clientes quando roubados ou falsificados causam problemas mais graves nas plataformas SaaS do que em um ambiente tradicional porque o provedor normalmente hospeda e gerencia os dados de inquilinos diferentes. E para minimizar os custos de hardware e de energia, os provedores armazenam dados de diferentes clientes no mesmo servidor compartilhado. Assim, se o provedor incapaz de garantir o isolamento completo dos dados e proteo, um cliente mal-intencionado pode roubar dados pertencentes a outros inquilinos ou modificar dados e comprometer a sua integridade. Ter uma plataforma comum e dados compartilhados aumenta muito a eficcia dos ataques comuns tradicionais, como o Sequestro de Sesso, Cross-site Scripting e SQL Injection.

3.9

AMEAAS A REDE

O SaaS remoto por definio, portanto, requer comunicaes baseadas em rede, na forma de protocolos. O provedor configura um aplicativo

32

para usar um protocolo inseguro. Basicamente o aplicativo passa as informaes entre o cliente e o servidor com um protocolo que no assegura a confidencialidade ou a Integridade. Isto ocorre em dois contextos principais: como usurio e como administrador. Aplicaes que usam protocolos inseguros, como Telnet para remoto acesso, FTP para transferncia de arquivos, POP e IMAP para E-mail, e HTTP para acesso web iro expor seus dados para algum ao longo do caminho da comunicao, alerta Cox (2010). Pensar na adoo do modelo SaaS leva o contratante (cliente) migrao do modelo baseado em intranet para um modelo baseado em internet. Tal modelo completamente fora do controle, tanto do contratante, (cliente) como do contratado (provedor), levantando, assim, vrias questes de segurana. As ameaas comuns voltadas rede como sniffing, flood e

tampering afetam diretamente a confidencialidade, integridade e disponibilidade da comunicao, uma vez que o servio disponibilizado atravs da internet.

3.10 AUTENTICAO

Henrique (2011) descreve um estudo da Forrester Research que pesquisou entre 306 (trezentas e seis) organizaes que migraram para o uso de servios baseados na nuvem, tal estudo chegou concluso que mais da metade (54%) das companhias entrevistadas passaram por problemas de segurana no ltimo ano. O autor ainda afirma que de acordo com a pesquisa, mesmo com o aumento significativo de solues de segurana, a grande maioria das empresas continua usando o tradicional mtodo de autenticao login e senha para verificar a identidade do usurio, em vez de adotar medidas mais fortes. Para um aplicativo SaaS ser acessado via rede, o controle de acesso obrigatrio e no pode ser baseado em endereos de rede, devido a possveis falsificaes. Nem todas as arquiteturas de autenticao so adequadas para um controle de acesso SaaS, por exemplo, compartilhar o mesmo mecanismo de autenticao entre aplicaes SaaS e as baseadas em servidor deve ser absolutamente evitado, pois h o risco de um fornecedor se apoderar de uma

33

credencial de autenticao, vlida no apenas na aplicao SaaS, mas tambm para outras aplicaes de clientes no hospedados neste provedor. Segundo Cox (2010), a autenticao e autorizao so funes que devem ser separadas a partir da lgica de aplicao quando se deslocam para o paradigma SaaS. O autor ainda afirma que elas devem se tornar autossuficientes e atuar como componentes externos da aplicao SaaS. Isto significa que podem ser configurados de forma independente do software principal do aplicativo. Por exemplo, hospedados em um provedor diferente ou ainda melhor geridos diretamente pelo cliente com um esquema single-sign-on (SSO), que ser proposto neste estudo de gerenciamento de autenticao SaaS, contextualizam Agrawall et al. (2011). Na prxima seo ser

apresentado a soluo proposta para o modelo de gerenciamento de segurana para a soluo SaaS.

34

4 GERENCIAMENTO NO CLICO DE VIDA DE DESENVOLVIMENTO SAAS

Segundo Moreira et al. (2011), o gerenciamento de um ambiente na nuvem possui caractersticas da plataforma diferentes SaaS deve dos ambientes no comuns. momento O do

gerenciamento

comear

desenvolvimento do aplicativo, e nesta etapa que as ameaas devem ser identificadas e os riscos analisados para uma possvel implementao de controles especficos que tratem estas ameaas. Rittinghouse & Ransom. (2010) citam fases de boas prticas que devem ser religiosamente implementadas no ciclo de vida do desenvolvimento de aplicativos SaaS, que so:

1. Investigao: nesta fase todos os processos e metas devem ser documentados nas polticas de segurana. 2. Analise: analisar cuidadosamente as polticas de segurana, examinar questes legais, executar as anlises de riscos, assim como as atualizaes das novas ameaas. 3. Projeto Lgico: nesta fase se deve projetar um plano de respostas a incidentes e desastres, assim como no descartar a viabilidade de uma possvel terceirizao do projeto. 4. Projeto Fsico: nesta fase se deve analisar tecnologias para auxiliar no projeto de segurana, e criar medidas de segurana para suportar novas solues. 5. Implementao: nesta fase se deve possuir um pacote testado para implementar a gesto de segurana da aplicao, analisar as premissas de compra ou desenvolvimento de solues para ajudar em tal gerenciamento. 6. Manuteno: esta fase se estende por todo o processo em que se deve monitorar, modificar, testar, reparar e atualizar as respostas s mudanas das ameaas.

35

No modelo de gerenciamento no ciclo de vida do desenvolvimento, o cdigo do aplicativo tambm deve ser escrito de maneiras mais consistentes, para assim, facilitar o processo de auditabilidade e reforo do cdigo. Todos os quadros e mdulos do aplicativo devem ser testados para os problemas de segurana com testes de penetrao interna e externa antes de serem implementados. A implantao de padres e requisitos de segurana com base na classificao dos dados no deve ser deixada para traz. Assim, a implementao do gerenciamento da segurana no principio do desenvolvimento, pode minimizar danos futuros.

4.1

GERENCIAMENTO DE IDENTIDADES As soluo SaaS uma arquitetura moderna baseada nos conceitos de

aplicao web, que possibilita a comunicao entre o contratante e o contratado, sendo este ltimo quem utiliza as solues de criptografia para os trfegos de dados. A comunicao que se d atravs de canais pblicos que facilitam o acesso e a busca dos clientes por solues, que sejam capazes de integrar em seu ambiente de trabalho padres de gesto de identidade, e a existncia de outros em busca de provedores de SaaS que possam garantir a segurana dos seus dados, traz uma dicotomia que passa a exigir de forma direta que a soluo SaaS seja capaz de tratar e/ou manusear modelos de autenticao internas, autorizao e federao, em que para este ltimo necessrio que o servio possua pontos de integrao, como repositrios internos para aqueles que no possuem produtos de gerenciamento de identidade, de acordo com Mather et al. (2009). Esta monografia ir propor um modelo de gerenciamento para possveis estudos e implementaes.

4.2

MODELO DE GERENCIAMENTO DE USURIO PARA AUTENTICAO CENTRALIZADA

36

O mtodo mais vivel de autenticao quando o fornecedor SaaS mantm um banco de dados independente da administrao de qualquer cliente, conforme apresentado na Figura 10.

Figura 10 - usurio e permisses contidas em banco de dados independente. Fonte: Software (2008).

A Figura 10 demonstra um exemplo geral de um usurio em um site onde o mesmo tem suas permisses contidas em um banco de dados dentro de uma pilha de SaaS. Esta metodologia comumente desenvolvida dentro de uma arquitetura SaaS devido simplicidade de implementao. No entanto, importante fazer uma distino entre autenticao e autorizao para que os usurios que chegam possam ser canalizados atravs de um mdulo de autorizao unificada. Assim, a Figura 11 apresenta um modelo de caso de uso expandido e um diagrama de sequncia para tal requisito que envolver apenas o usurio final e o gerente da soluo SaaS.

37

Figura 11 - Modelo de gerncia de usurio

A Figura 11 demonstra o diagrama de caso de uso do modelo de gerenciamento, ressaltando apenas os atores, usurio final e gerente SaaS, em que o gerente possui a capacidade de inserir, remover, alterar e buscar os usurios, e o ator usurio aps a autenticao possui privilgios regulares sobre a aplicao. J a Tabela 1 demonstra o caso de uso expandido do gerenciamento de usurio. Prticas exercidas pelo gerente SaaS.

Caso de uso: Gerncia de usurio

1. Inserir usurio

O usurio informa ao sistema os dados para cadastro: nome, senha, login e tipo pessoa, caso o usurio for Pessoa Fsica (endereo, telefone, RG, rgo emissor, profisso); caso o usurio for Pessoa Jurdica (tipo pessoa fsica, Nome Fantasia, CNPJ, Inscrio Estadual).

38

2. Buscar usurio O ator acessa o sistema, se identifica, acessa a rea Buscar Usurio. Informa os dados do tipo de usurio e confirma a ao

3. Alterar usurio

O usurio informa ao sistema novos valores os dados e confirma a ao.

4. Excluir usurio O sistema apresenta uma lista de usurio separado pelo tipo ordenado, pelo nome. O usurio seleciona um usurio da lista para excluso.

5. Inserir Permisso

O gerente SaaS seleciona no sistema o tipo de permisso que ser dada aos usurios, ou utiliza as permisses de negcio uma vez se houver federao SSO

6. Buscar Permisso O sistema apresenta formulrio com nome | CPF para pesquisar dados da permisso. O usurio digita o nome | CPF e seleciona a opo Ok. O sistema apresenta dados dos tipos de permisso. O sistema utiliza as permisses de negcio caso a operao seja voltada a federao SSO

7. Alterar Permisso

39

O usurio informa ao sistema novas permisses para o usurio, pode escolher um novo papel para o usurio ou um novo mdulo do sistema.

8. Remoo da Permisso O sistema apresenta uma lista de permisso ordenada por tipo. O usurio seleciona um elemento permisso da lista para excluso.

Tabela 1- Gerncia de usurio

A Figura 12 apresenta um diagrama de sequncia onde o ator gerente esta inserir um usurio que ficar armazenado em um bando de dados independente, e aps todas as verificaes necessrias, o mesmo recebe na pgina de gerenciamento a mensagem de confirmao do cadastro.

40

Figura 12 - Diagrama gerenciamento de insero de cadastro

O prximo diagrama de sequncia, Figura 13, mostra outra prtica do gerente SaaS, em que o mesmo acrescenta ao usurio permisses para a formulao do ambiente aps a autenticao do usurio. Esta prtica apenas acontece caso o gerenciamento no adotar outras solues como a de Federao SSO (Single SignOn), que ser vista com mais detalhes.

41

Figura 13 - Diagrama de sequncia de gerenciamento de permisses.

Aps a visualizao dos feitos do gerente de SaaS,

sero

apresentados os processos de autenticao do usurio final. A Tabela 2 apresenta o modelo de caso de uso expandido da autenticao do usurio final. Prticas para um melhor gerenciamento de autenticao do usurio final.

42

Caso de uso: Autenticar Usurio

Ator:

Usurio Final

Interessado:

Usurio Final

Pr-condies:

Os devidamente

usurios

devem

estar para

cadastrados,

assim, poderem fornecer login e senha Ps-condies: Autenticao no sistema

Responsabilidade:

Autenticar o usurio

Descrio:

Demonstra como um usurio pode obter acesso ao sistema.

Variaes tecnolgicas:

A autenticao dever ser efetuada por meio de formulrios que utilizam certificao digital utilizando criptografia com chaves assimtricas. O mesmo ser instalado no servidor que utilizar de protocolos HTTPS, assim, quando seus o usurio dados for

autenticado

estaro

criptografados .

Fluxo Principal:

O usurio acessa a pgina principal do sistema e localiza o formulrio de login, preenche os campos e submete os dados para o sistema. O usurio redirecionado

43

para a pgina inicial do sistema.

Autenticar o usurio

Aes do ator

Aes do Sistema

1. O usurio acessa o sistema 2. O usurio preenche os dados de login e senha

1. O sistema exibe a tela inicial 2. O sistema processa os dados do usurio e redireciona para a sua pgina inicial 3. O sistema armazena na base de dados a data e a hora do acesso.

Tratamento de Erros:

1. Senha ou login invlidos O usurio informado que o login e a senha so invlidos 2. O usurio no pode logar no sistema O usurio informado que o sistema esta bloqueado, o sistema exibe uma mensagem de erro e retorna o usurio para o passo 2(aes do ator)

Tabela 2- Autenticar Usurio.

O diagrama de sequncia abaixo demonstra a solicitao de autenticao do usurio final para acessar a plataforma SaaS.

44

Figura 14 - Diagrama de Sequncia de autenticao do usurio final.

4.3

MODELO DE GERENCIAMENTO DE USURIO PARA AUTENTICAO DECENTRALIZADA Uma soluo complementar ao estudo visto no tpico 3.2 a

implementao de um modelo no qual os usurios possa autenticar diretamente de seu sistema de autorizao. Geralmente, isso significa que o usurio est logado em um domnio da empresa, e tem o acesso ao provedor de SaaS, sem a necessidade de um segundo login. Isto permite ao cliente fazer cumprir todas as polticas de segurana necessrias em torno de

gerenciamento de identidade com o benefcio adicional de que os recursos e os riscos associados ao gerenciamento de identidade esto sendo transferidos para o cliente. A soluo que se aplica a tal proposta possvel com o uso da federao Single Sign On (SSO), que pode ser implementada atravs de token ou afirmaes (SAML). Para este trabalho, Security Assertion Markup

45

Language (SAML) utilizado devido ao seu lugar bem estabelecido na comunidade da Internet. Quando os clientes costumam usar LDAP dentro da sua organizao, SAML que fornece o mecanismo para que as informaes de identidade sejam transmitidas com segurana para o provedor de SaaS. Nas prximas linhas ser visto um cenrio do uso de Single SignOn (SSO) que pode utilizar o cenrio de chave de validao com cenrio chave titular (HOK) que usa tokens SAML com o mtodo de confirmao em vez do mtodo de confirmao ao portador. Tokens SAML HOK contm uma chave que o cliente utiliza para comprovar a propriedade da chave e a posse do token. Esta chave quando incorporada pode ser uma chave partilhada (tambm conhecida como uma chave simtrica) ou um certificado X.509 com uma chave pblica (tambm conhecido como uma chave assimtrica). No caso de uma chave compartilhada, a chave criptografada usando a chave pblica, destinada ao prestador de servios de negcio de modo que apenas o servio de negcio pretendido pode consumir as mensagens SOAP. Quando um cliente solicita tokens SAML com a HOK chave compartilhada de um STS (Security Token Service), STS criptografa a chave no tokens SAML e envia uma cpia da mesma chave na resposta WS-Trust para o cliente solicitante. Isto necessrio porque, caso contrrio, o cliente no pode ler as chaves criptografadas no tokens SAML. Para comprovar a propriedade dos tokens SAML, o cliente usa a chave compartilhada para assinar e para criptografar as mensagens de solicitao SOAP. A soluo SaaS pode validar a HOK propriedade token, extrair a chave criptografada compartilhada e us-lo para verificar a assinatura digital. O usurio ento utiliza tokens SAML para acessar a soluo SaaS. A empresa prestadora de servios valida os tokens SAML e afirma a identidade e os atributos do usurio com base na relao de confiana entre o prestador e os STS. Os tokens SAML recebidos so considerados vlidos se os certificados de assinatura de token so confiveis pelo provedor de servios de negcio e se o tempo de expirao dos tokens inferior ao tempo de provedor de servios de negcios local.

46

Figura 15 - Uso do SSO. Fonte: (Software, 2008).

A Figura 15, mostra um usurio tentando acessar um provedor SaaS em que o mesmo ir utilizar um token SMAL HOK criptografado atravs de STS. Esta autenticao se dar no diretrio do usurio atravs de uma chamada SOAP que o mesmo diretrio ir responder a autorizao e confirmao de autenticao, assim, quando os tokens SAML recebidos so considerados vlidos e os certificados de assinatura de token so considerados confiveis pelo provedor SaaS, a autorizao ao servio se d por completa.

4.4

MODELO DE GERENCIAMENTO DE LOG Devido utilizao da Internet pblica, o movimento de dados da

plataforma SaaS para o cliente quase idntica aos desafios de segurana que se colocam em outros modelos de negcios, tais como o modelo ASP. ASP e SaaS usam a Internet sem garantia pblica para transmitir dados. Estes desafios de segurana so abordados por abraar trs conceitos principais: No-repdio - Destinatrio dos dados tem provas de que os dados foram originados a partir do provedor SaaS.

47

Confidencialidade - Os dados s podem ser visualizados pelo destinatrio.

Integridade - Os dados no podem ser alterados sem deteco.

Estes trs conceitos devem ser tratados por igual, como um grupo, j que, se a soluo for dada para apenas um caso em especifico, ser muito abrangente e as outras no sero tratadas nem gerenciadas. Considera-se uso de ferramentas como SSL ou criptografias TLS tratando o trfego entre o servidor Web e o cliente, j que estes protocolos so projetados para evitar a espionagem, adulterao e falsificao. Assim, um processo automatizado deve ser construdo para o gerenciamento dos logs de auditoria diria. Devido grande quantidade de acesso que supostamente um aplicativo SaaS possui e a diversidade de meios eletrnicos para tal acesso, importante manter registros de provas que demonstrem a origem de todas as entradas, como alteraes, adies, excluses e aprovaes. O log de auditoria deve ser criptografado e mantido em um segmento de rede que os engenheiros de sistemas no tenham acesso, a fim de manter a integridade do log. A figura abaixo mostra um diagrama de caso e uso, em que apresenta o papel do usurio (contratante do servio) e o gerente SaaS (contratado) com suas respectivas funes diante do log do sistema.

48

Figura 16 - Diagrama de caso de uso Log.

A Figura 16 mostra o comportamento do gerente SaaS e o usurio diante do log do sistema. O gerente pode configurar o log, visualizar e emitir o relatrio do log, j o usurio pode apenas visualizar. Este modelo de gerenciamento possibilita ao gerente de SaaS tentar garantir a integridade do log. O gerenciamento da entrada e sada do usurio dos sistema, e o que o mesmo faz que no esteja de acordo com a regra de negcio, sempre deve ser armazenado de forma segura para facilitar uma possvel investigao e o uso da no-repdio. O gerenciamento do log deve ocorrer no incio da conexo do cliente ao aplicativo, para, assim, possibilitar a identificao de um possvel intruso, ou, caso algum ataque acontea, saber se o usurio agiu com m inteno. A Figura 17 mostra um modelo e gerenciamento de log.

49

Figura 17 - Gerenciamento de log. Fonte: Mota, 2009.

A Figura 17 apresenta o modelo de gerenciamento de log no momento da entrada do usurio, armazenando o horrio e a data em que houve a autenticao no sistema. O log principal de acesso, e o modulo, pode ser ativado devido s regras de negcio, e em cada empresa, sempre as funes

50

de gerenciamento devem ser ativadas, mesmo se a empresa no possua regra de negcio definida. Falar de gerenciamento de log e no especificar um modelo de auditoria tornaria todo o processo ineficiente. Na atualidade, no mercado de servio h normas de auditoria e a mais usada para o segmento de estudo a norma internacional SAS 70, que permite s empresas fornecedoras de SaaS elaborar um relatrio confivel de suas prticas de controles internos. Em abril de 2011 o AICPA (http://www.aicpa.org), anunciou que a SAS 70 (Statementon Auditing Standards No. 70) era para ser substituda por SSAE 16. SSAE 16 a prxima gerao de AICPA, normas para elaborao de relatrios sobre os controles nas organizaes de servios, incluindo software como prestadores de servio, nos Estados Unidos. SSAE 16 vai alm do SAS 70, no s verificar os controles e processos, mas tambm exigir uma declarao escrita sobre a eficcia de design e operacional dos controles sendo revisados. Alm disso, SSAE 16 adotada e fortemente alinhada com as Normas Internacionais para trabalhos de assegurao (ISAE) 3402, o novo padro de auditoria internacional para prestadores de servios. Ambas as entidades (AICPA e ISAE) alinhadas cada um com seus respectivos padres.

51

5 CONCLUSO
O modelo SaaS vem crescendo exorbitantemente junto ao mercado de TI, dividindo-o em dois segmentos: o dos aplicativos baseados em servidores e os aplicativos baseados na nuvem. Entretanto, quando a questo envolve dados confidenciais, tudo muda de histria, uma vez que informaes de grandes empresas utilizam canais que envolvem protocolos web para acesso, fazendo da segurana o fator primordial para este novo paradigma. Este trabalho de concluso de curso props um estudo de reviso bibliogrfica sobre SaaS, ressaltando seus aspectos econmicos, tericos, de desenvolvimento, segurana e vulnerabilidades que assolam tal modelo, assim como mostrou subsdios para ajudar na construo de um modelo de gerenciamento de identidade. A reviso foi desenvolvida com base em pesquisas bibliogrficas, que envolveram livros, artigos, publicaes e sites. A reviso de literatura abordou conceitos fundamentais para a compreenso da plataforma SaaS mostrando as melhores prticas que devem ser utilizadas no processo de adoo desta plataforma, ajudando para demonstrar um mtodo de autenticao gerenciada e boas prticas para o armazenamento e gerenciamento dos logs para possveis auditorias. Na proposta do modelo de gerenciamento foi utilizada a ferramenta UML para a manipulao de diagramas, como os de caso de uso e o de sequncia, para os processos de gerenciamento de autenticao e dos logs, sendo visto tambm os conceitos de criptografia Tokens SAML para o modelo de autenticao e a proposta de um novo modelo de auditoria SSAE 16 Contudo, este estudo mostrou formas de como se prevenir de possveis ameaas antes da implementao de ferramentas para suporte, uma vez que a segurana no modelo SaaS deve ocorrer no momento da escolha do fornecedor. As especificaes da documentao SLA, que possui as diretivas acordadas para o uso e fornecimento do servio, mostrou meios para o gerenciamento das principais rotinas de um sistema SaaS. Pensando nos trabalhos futuros, sugere-se os seguintes temas:

52

Promover a implementao do modelo que foi proposto Promover o desenvolvimento de sistemas de gerenciamento de um SLA Promover um estudo sobre STS (Security Token Service)

53

6 REFERNCIAS

AGRAWAL, D.; CANDAN, K.; LI, W.-S. New Frontiers in Information and Software as Services. . [S.l: s.n.]. , 2011

ANDERSOM, C. A Cauda Longa: do mercado de massa para o mercado de nicho. 5. ed. [S.l: s.n.], 2006.

BLOKIDIJK, G. SaaS 100 success secrets: how companies sucessfully buy, manage, host and deliver software as a service (SaaS). . [S.l: s.n.]. , 2008

BORGES, H. P.; SOUZA, J. N. D.; SCHULZE, B.; MURY, A. R. Desenvolvimento automtico de aplicaes e plataformas de trabalho em nuvens computacionais. Science And Technology, 2010. BRIVO. SaaS TCO. System. [S.l: s.n.]. , 2009

BRODKIN, J. 5 questes a considerar sobre segurana em SaaS. Disponvel em: <http://computerworld.uol.com.br/seguranca/2011/09/28/5-

questoes-a-considerar-sobre-seguranca-em-saas/>. Acesso em: 12 jan. 2012.

CARRARO, G.; CHONG, FRED. Software como Servio (SaaS): uma perspectiva corporativa. Disponvel em: <http://msdn.microsoft.com/pt-

br/library/aa905332.aspx>. Acesso em: 12 maio. 2012.

CHONG, FREDERICK; CARRARO, G. Estratgias de Arquitetura para Cauda Longa (Long Tail). Disponvel em: <http://msdn.microsoft.com/ptbr/library/aa479069.aspx>. Acesso em: 20 jun. 2012.

COX, P. SaaS Threats In The Cloud. Consultant. [S.l: s.n.]. , 2010

54

DAS, C.; MOHAN, G.; ROY, R.; BHATTACHARYA, S. Quo vadis, SaaS a system dynamics model based enquiry into the SaaS industry. Information Management and Engineering. . (ICIME): IEEE International Conference on , vol., no., pp.732-737, 16-18 April 2010. , 2010

DESISTO, R. P.; DARYL C., P.; SMITH, D. M. A relao entre Computao em nuvem e SaaS. Disponvel em: Acesso

<http://info.abril.com.br/corporate/noticias/072008/28072008-1.shtml>. em: 21 fev. 2012.

GREER, M. Software as a Service Inflection Point. [S.l: s.n.], 2009.

GRUMAN,

G.;

PITA,

M.

verdade

sobre

SaaS.

Disponvel

em:

<http://cio.uol.com.br/tecnologia/2007/11/27/idgnoticia.2007-1127.7670603730/paginador/pagina_4>. Acesso em: 20 jun. 2012.

HE, H. Applications Deployment on the SaaS Platform. Business. [S.l: s.n.]. , 2010

HENRIQUE, F. Ataques nuvem indicam necessidade de autenticao forte. Disponvel em: <http://saasbr.wordpress.com/2011/01/23/ataques-a-

nuvem-indicam-necessidade-de-autenticacao-forte/>. Acesso em: 22 jun. 2012.

KOMMALAPATI, H.; ZACK, W. H. Ciclo de vida de desenvolvimento SaaS. Disponvel em: <http://www.infoq.com/articles/SaaS-Lifecycle>. Acesso em: 11 maio. 2012.

KOTHARI, C. J. Atendendo Requisitos de Segurana de Aplicativos de Software como Servio (SaaS). Disponvel em:

<http://www.ibm.com/developerworks/br/library/ar-saassec/>. Acesso em: 21 jun. 2012. MATHER, T.; KUMARASWAMY, S.; LATIF, S. Cloud Security and Privacy.pdf. [S.l: s.n.], 2009.

55

MCAFEE. As ameaas virtuais crescem e os oramentos caem. . [S.l: s.n.]. , 2010.

MELO, C. A.; ARCOVERDE, D. F.; MORAES, . R. A.; PIMENTEL, J. H. C.; FREITAS, R. Q. Software como Servio: Um Modelo de Negcio Emergente. . Recife-PE: Centro de informtica - Universidade Federal de Pernambuco. , 2007

MOTA, V. P. Desenvolvimento da modelagem de uma ferramenta para gerenciar aplicaes SaaS. . [S.l: s.n.]. , 2009 PEDRO, V.; PINHO, F. D. SaaS: Anlise de impacto na transformao da investigao e desenvolvimento de produto para servio. 2009.

RAMOS, F. Gesto de Risco e Compliance: O que vem antes? Disponvel em: <http://axurblog.blogspot.com.br/2007/10/gesto-de-risco-e-compliance-o-

que-vem.html>. Acesso em: 20 jun. 2012.

RANE, P. Protegendo aplicativos SaaS: uma perspectiva de segurana em nuvem para fornecedores de aplicativos. Disponvel em:

<http://translate.google.com/translate?hl=ptPT&langpair=en|pt&u=http://www.infosectoday.com/Articles/Securing_SaaS_Ap plications.htm>. Acesso em: 21 jun. 2012.

RITTINGHOUSE, J.; RANSOME, J. Cloud Computing: implementation, managemet and security. . [S.l: s.n.]. , 2010

RUSCHEL, H.; ZANOTTO, M. S.; COSTA, W. Computao em Nuvem. Computing, 2010. SIIA. Software as a Service: Strategic Backgrounder. Online. [S.l: s.n.]. , 2001 SOFTWARE, P. SaaS Security and privacy. 2008.

56

WITHINK.

Conceito

arquitetura.

Disponvel

em:

<http://wethinkbs.wordpress.com/category/saas-software-as-aservice/page/2/>. Acesso em: 2012.

WOLTER, R.; CARRARO, G.; CHONG, FREDERICK. Arquitetura de dados para mltiplos inquilinos. Disponvel em: <http://msdn.microsoft.com/ptbr/library/aa479086.aspx>. Acesso em: 15 jul. 2012.