C.E.S.A.

R - CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE

CLOVES ALBERTO CHAVES DE LIMA

UM MODELO DE GERENCIAMENTO DE IDENTIDADE PARA SEGURANÇA DE APLICATIVOS SAAS

RECIFE, 2012

ii

C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE

UM MODELO DE GERENCIAMENTO DE IDENTIDADE PARA SEGURANÇA DE APLICATIVOS SAAS

Monografia apresentada ao programa de Especialização de Segurança em Engenharia de Software do Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R, como requisito para a obtenção do título de Especialista em Engenharia de Software com ênfase em Segurança. Orientação: Prof. Vinicius Cardoso Garcia

RECIFE, 2012

iii

C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS DO RECIFE

UM MODELO DE GERENCIAMENTO DE IDENTIDADE PARA SEGURANÇA DE APLICATIVOS SAAS CLOVES ALBERTO CHAVES DE LIMA

Monografia apresentada ao programa de Especialização de Segurança em Engenharia de Software do Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R, como requisito para a obtenção do título de Especialista em Engenharia de Software com ênfase em Segurança.

Data de aprovação: _____ / _____ / 2012.

Banca examinadora:

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

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

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

iv

A meus dois grandes amores (mãe e noiva), que me deram força necessária na hora certa, acreditaram que eu era capaz e não me deixaram desanimar em nenhum momento. Obrigado por tudo amo vocês!.

v

AGRADECIMENTOS

Este trabalho é o culminar de um percurso de crescimento pessoal no qual o contributo de algumas pessoas se revelou fundamental. Impõe-se, por isso, expressar neste espaço, o meu reconhecimento. Primeiramente a Deus, que é a razão principal de minha existência 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 não se faria. A minha querida mãe Messelene de Fátima , que foi minha inspiração pela sua história de vida e que sempre acreditou que seria possível, confiando em mim quando nem eu mesmo acreditava. A minha futura esposa Elizabeth Araújo que sempre esteve comigo, nas horas boas e difíceis, que no momento de fraqueza quando estava prestes a desistir me fez entender que era possível persistir, e que sempre entendeu a minha ausência como sendo uma etapa passageira de minha vida, e é por esse motivo que estou aqui, te amo. Ao meu orientador Vinicius Cardoso pela paciência e sabedoria. Em fim, agradeço a todos os amigos que diretamente ou indiretamente ajudaram a concluir esse trabalho. “Começar é para muitos, continuar é para poucos e terminar é para VITORIOSOS”.

.

vi

RESUMO

O aumento exponencial do poder de processamento, o amadurecimento da virtualização, arquiteturas orientadas a serviços e uma maior largura de banda, forneceram subsídios 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 negócio remotamente através 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 utilização deste serviço ainda é bastante vulnerável Este trabalho é um estudo de revisão bibliográfica que tem como objetivo abordar o modelo SaaS, descrevendo assim a arquitetura, vantagens e desvantagens, os modelo econômico, e suas visões. Por fim, estudaremos as vulnerabilidades deste serviço e as principais dúvidas encontradas no momento da escolha de tal modelo. Apresentaremos também, os métodos de gerenciamento de identidade e meios de gerenciamento de controles para fornecer maior segurança para a escolha deste aplicativo, tais propostas serão mostradas através de estruturas UML.

Palavras-chave SaaS, gerenciamento de identidade, segurança, ameaças, 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 RELAÇÃO COM MODELO DE NEGÓCIO, ARQUITETURA DA APLICAÇÃO 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 - DIVISÃO TÍPICA 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 INSTALAÇÃO 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 PRÓPRIO 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 - USUÁRIO E PERMISSÕES CONTIDAS EM BANCO DE DADOS INDEPENDENTE. FONTE: SOFTWARE (2008). FIGURA 11 - MODELO DE GERÊNCIA DE USUÁRIO FIGURA 12 - DIAGRAMA GERENCIAMENTO DE INSERÇÃO DE CADASTRO FIGURA 13 - DIAGRAMA DE SEQUÊNCIA DE GERENCIAMENTO DE PERMISSÕES. FIGURA 14 - DIAGRAMA DE SEQUÊNCIA DE AUTENTICAÇÃO DO USUÁRIO 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- GERÊNCIA DE USUÁRIO. TABELA 2- AUTENTICAR USUÁRIO. 39 43

x

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 Informação 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

SUMÁRIO

LISTA DE FIGURAS .................................................................................................................. VIII LISTA DE TABELAS ................................................................................................................... IX LISTA DE SIGLAS ........................................................................................................................ X SUMÁRIO..................................................................................................................................... XI 1 2 INTRODUÇÃO ...................................................................................................................... 1 DEFINIÇÃO – 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 SERVIÇO ......................................................... 7 ANÁLISE 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 SEGURANÇA SAAS ................................................................................................... 26 GESTÃO DE RISCOS SAAS ....................................................................................... 28 VULNERABILIDADES SAAS ...................................................................................... 28 MAU COMPORTAMENTO DO SERVIÇO .................................................................. 29 COMPUTAÇÃO CONFIÁVEL ..................................................................................... 29 VIOLAÇÃO DOS DADOS DOS CLIENTES ................................................................. 30 COMPARTILHAMENTO DE RECURSOS .................................................................. 31 AMEAÇAS A REDE ..................................................................................................... 31 AUTENTICAÇÃO ........................................................................................................ 32

4

GERENCIAMENTO NO CLICO DE VIDA DE DESENVOLVIMENTO SAAS .................... 34 4.1 GERENCIAMENTO DE IDENTIDADES ...................................................................... 35 4.2 MODELO DE GERENCIAMENTO DE USUÁRIO PARA AUTENTICAÇÃO CENTRALIZADA ..................................................................................................................... 35 4.3 MODELO DE GERENCIAMENTO DE USUÁRIO PARA AUTENTICAÇÃO DECENTRALIZADA ................................................................................................................ 44 4.4 MODELO DE GERENCIAMENTO DE LOG ................................................................ 46

5 6

CONCLUSÃO ..................................................................................................................... 51 REFERÊNCIAS ................................................................................................................... 53

1

1 INTRODUÇÃO
Software as a Service (SaaS) caminha para se tornar um dos segmentos de tecnologia da informação 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 não tinham outra opção senão hospedar seus softwares em suas próprias infraestruturas, rodando-os em seus servidores, o que gerava altos gastos com licenciamento de software e também com o parque tecnológico. Segundo (DAS et al., 2010), SaaS é uma forma de entregar as funcionalidades de software através da Internet a partir de uma única instância de aplicação, sendo compartilhada entre todos os usuários uma única cópia de software, que pode ser disponibilizada aos consumidores sob demanda como serviço compartilhado, sendo acessível através de uma rede com localização remota, onde é cobrado uma assinatura ou pagamento pela quantidade de uso. O SaaS tem como característica fornecer um aplicativo a vários clientes e empresas de forma simultânea, utilizando a fundamentação de cauda longa, uma vez que, o objetivo SaaS é fornecer o mesmo software para um maior número de clientes(contratantes) possíveis. Para que os fornecedores possam distribuir SaaS ao invés de fornecer software pelo modelo tradicional, (CHONG & CARRARO, 2006) expõem as mudanças quanto a forma do fornecedor (contratado) pensar, são elas: o modelo de negócios, 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 vários clientes pela Internet, em troca de uma taxa. No entanto, na prática, as características marcantes entre um aplicativo instalado no local do cliente e um aplicativo SaaS não são as características binárias, e sim, três distintas dimensões, 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 comparação às práticas de

2

desenvolvimento de software tradicionais), SaaS está provando ser uma tendência divisora de TI. Uma das principais características 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 são: segurança, customização,

Arquitetura Orientada a Serviços (SOA) e integração, que estão relacionados diretamente na arquitetura SaaS (KOTHARI, 2011). A segurança é de suma importância na arquitetura do aplicativo SaaS, pois os dados e processos serão hospedados fora das instalações de uma organização. Em um modelo tradicional de implantação do aplicativo, os dados confidenciais de cada empresa continua a residir dentro dos limites da empresa e está sujeito à sua segurança física, lógica e pessoal, assim como políticas de controle de acesso. No entanto, no modelo SaaS, os dados da empresa são armazenados fora dos limites da empresa, consequentemente, o fornecedor de SaaS deve adotar verificações de segurança adicionais para garantir a segurança dos dados e evitar quebras, devido a vulnerabilidades de segurança no aplicativo ou através de funcionários mal-intencionados, isto envolve o uso de técnicas de criptografia fortes para garantir a segurança 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, organização, vantagens/desvantagens, custo, aspectos técnicos, segurança da plataforma e suas vulnerabilidades. Após tais conceitos, serão mostrados subsídios para propor um modelo de gerenciamento de identidade.

1.2 JUSTIFICATIVA Os benefícios da utilização de Software as a Service (SaaS) , que oferece soluções de software entregues por meio do modelo de computação em nuvem , são claras para muitas organizações e podem incluir significativa

3

economia de custo, produtividade e maior força de trabalho. No entanto, a adoção desses serviços também apresenta um grande desafio para os administradores de TI: o gerenciamento do controle de acesso. Na ausência de um gerenciamento eficaz da identidade do usuário, acesso e credenciais (capacidade de controlar quem está usando o aplicativo e quando), as organizações sofrem risco de comprometer a sua rede e segurança de dados. Eles também podem deixar de atender às demandas dos regulamentos de conformidade e o impedimento de uma investigação forense frente a um caso de perda de dados. Estas desvantagens podem minar os benefícios o do uso de soluções SaaS. Paralelamente, diante do gradativo crescimento do número de aplicações SaaS em uso nas empresas, a necessidade de uma fácil e eficaz maneira de administrar o acesso das soluções SaaS traz consigo uma série de soluções de controle de gerenciamento. Somando-se ao desafio de controle de acesso, na empresa de hoje, as pessoas têm trabalhado em mais lugares fora da organização, e com mais tipos de dispositivos para atender a várias aplicações e dados sensíveis.

4

2 DEFINIÇÃO – SOFTWARE AS A SERVICE SAAS
O SaaS é um software distribuído como um serviço e é implementado em uma plataforma web, utilizando as tecnologias e protocolos, não necessitando de instalações localmente (on-premise) e é pago por demanda, tempo de uso ou volume. Pode-se dizer que o mesmo usa mecanismos de tarifação métrica. Fornece uma API para acesso através de web services, interfaces REST, SOAP e/ou outros protocolos (CAMBIUCCI, 2009). O SaaS está inserido em dois contextos: o de linha de negócio em que o software é distribuído em larga escala e vendido por assinatura, e os serviços orientados a cliente que se dá quando o software é oferecido ao público gratuitamente (MOTA, 2009). Ainda de acordo com Motta (2009), o SaaS está mudando a forma do fornecedor pensar, uma vez que, oferece apenas o serviço em vez de fornecer software na maneira tradicional, levantando questões de um novo modelo de negócio, arquitetura de software e estrutura operacional.

Figura 1 - Estrutura do modelo SaaS relação com modelo de negócio, arquitetura da aplicação e estrutura operacional. Fonte: Chong et al (2006)

5

Na Figura 1, vemos a relação da visão do fornecedor com a alteração do modelo de negócio, há mudanças de algumas características com relação ao modelo tradicional de software como:  A propriedade do software do cliente para um fornecedor externo sofre significativas alterações.  Realocação da infraestrutura (parque tecnológico) e gestão, ou seja, hardware e serviços partem do cliente para o provedor.  O uso da economia de escala reduz o custo da prestação de serviço de software.  Pequenas empresas podem reduzir o custo que o software pode ser vendido utilizando os conceitos de cauda longa.

Na relação arquitetura de aplicativo o objetivo é que o cliente perceba que a utilização de SaaS é uma redução de custo em potencial comparado ao modelo tradicional, ou quando é pago pela assinatura do serviço (RUSCHEL et al., 2010). Em um ambiente de TI tradicional onde os softwares são 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)

6

De forma mais detalhada, a Figura 2 retrata a divisão de custo em ambiente de TI tradicional, onde o custo agregado a hardware se dá pelo gasto com o parque tecnológico, servidores para hospedar dados, aplicativos e componente para colocá-los na rede. O custo de profissionais de serviço, se dá a equipe de suporte responsável por implementar e realizar a manutenção do hardware e software, bem como, consultores e recurso de desenvolvimento para construir software personalizado, e a parte dos softwares que são as licenças. O modelo SaaS dá a possibilidade de desdobramento na utilização dos serviços, onde o cliente pode ceder o software locado para uso de terceiros, aos quais iremos nomeá-los de usuários finais. Portanto, o cliente pode desenvolver diversas relações de negócios com os usuários finais, podendo utilizar os meios de cobranças como: assinatura mensal ou anual, volumes de serviços pela utilização do software e serviço disponibilizado gratuitamente. No serviço disponibilizado gratuitamente o cliente busca outras formas de obter receita. Nessa modalidade, o cliente pode buscar parceiros ou cobrar por anúncios, caso tenha um grande fluxo de usuários. Além do custo inicial reduzido para o cliente, de acordo com Chong & Carraro (2006), “há uma porcentagem maior da receita disponível para gastar em software”, normalmente na forma de taxas de assinaturas, transações, ou por meio de anúncios. Por fim, a estrutura operacional também é alterada. Geralmente, o investimento com Tecnologia da Informação (TI) nas organizações é gasto em três áreas distintas como já foram transcritas acima que são: software, hardware e serviços profissionais (BLOKIDIJK, 2008). Segundo Mota (2009), o software é o que geralmente está mais envolvido no gerenciamento das informações, porém, em modelo de software local, a maior parte do investimento é gasto em hardware e serviços profissionais, ficando a outra parte disponível para software. A figura 3 apresenta a alocação de recursos em um ambiente SaaS.

7

Figura 3 - Divisão típica de investimento em ambientes SaaS. Fonte: Chong & Carraro (2006)

Na Figura 3, o fornecedor de SaaS hospeda aplicativos críticos e dados associados em servidores centrais, o suporte ao hardware e software é feito através de uma equipe de suporte dedicada, aliviando a organização do cliente e a responsabilidade de apoiar o software hospedado, para a aquisição e manutenção de hardware e servidor . Além disso, os aplicativos são 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 orçamento de TI são disponível para gastar em software, na forma de taxas de inscrição para os fornecedores de SaaS (CHONG &CARRARO, 2006). 2.1 CONCEITOS DE SOFTWARE COMO SERVIÇO Segundo SIIA (2001), o software como um modelo de serviço é capaz de causar uma mudança na indústria de software. No entanto, Software as a Service ainda deve superar vários obstáculos significativos à adaptação generalizada. O primeiro entre tais obstáculos pode ser a falta de clareza na definição dos próprios serviços de software. O mercado é dificultado por divergências sobre as características intrínsecas dos serviços e até mesmo a terminologia usada para descrever serviços de aplicativos. As definições estão

8

constantemente mudando, fustigada pela criação de novos modelos de negócios e tecnologias que as empresas utilizam para entregar a sua visão do software como um serviço. O mercado é inundado com siglas cada um representando uma abordagem um pouco diferente - de serviços provedor de aplicação (ASP), os provedores de infraestrutura de aplicações (AIP), de serviços de Internet de negócios (IBS), serviços provedor de negócios (BSP), prestador de serviços de soluções (SSP), entre outros. Portanto, para evitar confusão, SIIA (2001) se refere ao modelo geral de software como serviço.

No software como um modelo de serviço, o aplicativo ou serviço é implantado a partir de um centro de dados centralizados através de uma rede - Internet, Intranet, LAN ou VPN – de acesso e uso em uma base com taxa de retorno. Os usuários podem "alugar", "assinar", "atribuir", ou "ter acesso a", as aplicações de um provedor central (CARRARO & CHONG, 2007). Os modelos de negócio variam de acordo com o nível de simplificação do software, o baixo preço e o aumento da eficiência ou do valor acrescentado através das personalizações para melhorar os processos de negócio digital. O valor fundamental de software como serviço está no fornecimento do acesso e manejo, disponível comercialmente através de aplicações. Os benefícios potenciais do modelo são significativos tanto para o vendedor quanto para o cliente. Este serviço é diferente de Business Process Outsourcing (BPO), por exemplo, em que o contrato de terceirização abrange a gestão de processos de negócios.

O Software as a Service (SaaS), tornou-se uma ferramenta significativa para as indústrias de software, já que a mesma é tida como um modelo de negócio que centraliza e organiza informações, utilizando a internet e por custos menores quando comparado com softwares tradicionais (MOTA, 2009).

9

Segundo Cox (2010), o Software as a Service se define como um serviço hospedado e disponível pela internet e pode ser classificado em serviço orientado a cliente e serviço de linha de negócio, em que um software é distribuído em larga escala e vendido por assinatura, já o outro software é oferecido ao público gratuitamente e custeado por anúncios. Mas, há algumas divergências no contexto do uso da internet para a utilização desse modelo, assim, a análise 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 transferência dos bits, e representa o serviço, no entanto, não é utilizada de forma obrigatória, já a Microsoft afirma que a internet para este modelo é indispensável.

2.2

ANÁLISE DE CUSTO
A simples utilização de SaaS para a distribuição de serviço na web não é o motivo primordial para a sua adoção, para tal implementação há várias estratégias econômicas para garantir a receita e estudos de custos com estimativas de uso das funcionalidades, que estão sendo oferecidas pelo serviço (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, espaço no data center, acesso à rede, energia ,refrigeração, etc.) e processos (manchas de infraestrutura / upgrades, correções de aplicativos / upgrades, backups, etc.) necessárias para executarem e gerenciarem a solução completa. Porque os fornecedores de SaaS gerencia todos os seus clientes em uma única instância 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 solução SaaS pode ter um custo na faixa de 76% (setenta e seis por cento) menor que uma solução 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 solução SaaS ao longo de um tradicional sistema baseado em servidor. A primeira coluna (à esquerda) mostra o TCO de cinco anos de uma solução SaaS. A coluna seguinte (em vermelho) mostra a despesa acumulada mensal das taxas de SaaS, em comparação com um servidor instalado. No entanto, este pequeno déficit é rapidamente compensado pelas próximas três colunas, que representam as despesas com as categorias que são suportadas apenas pela solução de servidor. No efeito líquido, estas categorias somam um TCO muito maior para o sistema baseado em servidor. Nota-se que as economias de SaaS são alcançados sem levar em conta a despesa ou impacto nos negócios de inatividade do servidor, que pode ser considerável para muitos tipos de empresas. Quando estes fatores de

11

custos adicionais são inseridos, a eficácia do custo de solução SaaS é ainda mais dramática (BRIVO, 2009). Na Figura 5 vemos com mais visibilidade a relação do custo de despesas de implantação de um sistemas baseado em servidor com relação a uma implantação SaaS.

Figura 5 - Analise de custo instalação de sistemas baseado em servidor e SaaS. Fonte: Brivo, 2006

Contudo, a diferença de custo entre implementações de sistemas baseados em servidores é bem significativa em relação à solução SaaS. Entretanto, a solução deve estar inserida no quadro de análise a longo prazo, para que tal economia seja verdadeira. Por este motivo, no próximo tópico 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 disponível pela web para vários usuários e empresas ao mesmo tempo, gerando assim, uma economia de escala, onde uma empresa fornece um pequeno número de produtos para uma maior quantidade possível de consumidores (ANDERSON,2006).

12

Ao eliminar grande parte da manutenção, e utilizando a economia de escala para combinar e centralizar hardware dos clientes e os requisitos de serviços, fornecedores de SaaS podem oferecer soluções a um custo muito menor do que os fornecedores tradicionais, não só em termos monetários, mas também 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 inacessível aos fornecedores de soluções tradicionais, porque nunca foi rentável para servi-los (CHONG & CARRARO, 2006). Os fornecedores de solução SaaS, se defrontam com uma curva de negócio 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 manutenção de estoques, permitem calcular um valor para a procura que define a fronteira entre lucro e prejuízo (WITHINK, 2008, on line). No caso dos novos parâmetros da economia, este pensamento é colocado sobre questionamento, muito particularmente no caso dos produtos digitais. Por exemplo, o custo de manutenção de um produto muito procurado é igual ao custo de manutenção de um produto procurado apenas por um número mínimo de consumidores. Ainda o site Wething (2008) afirma que, apostar na cauda Longa, tornase economicamente interessante, pois conforme baixo custo de adoção, um número maior de clientes pode adotar tal solução. E esse número tende ao infinito, uma vez que a curva não toca o eixo “x” (Figura 6). Assim, no modelo SaaS de fornecimento de software, é necessário pensar em soluções e infraestrutura de baixo custo, com alto aproveitamento de recursos por um número muito grande de clientes, para se atingir um público não 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 gestão empresarial e tecnologia da informação, os contratos de TI mal elaborados proporcionam a maioria dos problemas nos projetos de terceirização. A mesma ainda define que é de suma importância a existência de uma definição compreensível dos termos contratuais, que possua um detalhamento completo dos serviços e produtos que estão sendo oferecidos, limites de atuação, formas de proteção, clara definição de abrangência, entre outros aspectos. Contratos como os da solução SaaS podem deixar as bases de contratação a desejar, se não houver uma análise minuciosa de todos os aspectos para a sua elaboração. A consequência é que os objetivos esperados não podem ser garantidos apenas por si mesmos, tendo de deixar de lado

14

fatores primordiais como a fórmula de composição, distribuição dos serviços e todas as suas vantagens. A confecção de um contrato adequado garante as suas funcionalidades e a concretização dos objetivos estratégicos que podem estar relacionados à adoção 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 serviços e um cliente sobre nível de serviços, em que o fornecedor se compromete a ressarcir o cliente pelo tempo em que a aplicação não estiver disponível. O SLA define parâmetros de negócios e/ou de suporte técnico que um provedor de serviço fornecerá a seu cliente, especificando medidas de performance e consequências por não atingir as netas ou falhas

Um contrato SLA define as responsabilidades que implicam entre o provedor (contratado) e a empresa responsável pela contratação, delimitando assim as devidas responsabilidades de ambas as partes, dentre essas incluem: funções repetitivas, definições, processos e também produtos que serão criados e entregues. Está inserida neste conjunto de acordos a delimitação de cada etapa do serviço, e suas restrições (PEDRO, 2009).

Além do conjunto de acordos que são inseridos no contrato SLA, é de grande importância que sejam utilizadas ferramentas que auxiliem durante o processo de gerenciamento. Quando os serviços 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 serviços. O gerenciamento das aplicações cliente-servidor em operação fica sob a responsabilidade do contratante que está com a posse da licença do software, diferindo da solução SaaS em que o problema é estritamente da contratada que fornece o serviço. Porém, existe também a possibilidade de terceirizar o serviço, solicitando um Data Center ou subcontratando um profissional especializado, responsabilizando este com multas, se o contrato não 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, segurança dos dados, dentre outros, e também é responsável por promover a funcionalidade do serviço que em algumas situações tem que suportar e manipular uma grande demanda de dados e continuar gerando respostas rápidas. Para que haja eficácia neste software é necessário o acoplamento com mão de obra, novas tecnologias, dentre outros. Quando o cliente utiliza as soluções tradicionais (baseada em cliente-servidor) se depara com custos bastante elevados, diferente da solução SaaS, uma vez que o próprio fornecedor do serviço se responsabiliza pela manutenção do software para o contratante, não sendo necessário

preocupação com custos elevados com o serviço, de acordo com Pedro et al. (2009). Borges (2010) afirma que “é de fundamental importância que qualquer software comercial garanta a segurança durante a transmissão de dados. Contudo, quando utilizamos a solução 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, além do fato de que todos os dados trafegam por essa rede. Já que esse conjunto é compartilhado, como deve ser garantida a segurança desses dados para que não ocorra invasão ou acesso do conteúdo pelo concorrente ou pessoas não autorizadas? Para garantir a eficiência na segurança da transmissão dos dados pela internet, é realizada a solução criptografia em níveis elevados. Essa, por sua vez, se dá por meio de chaves criptográficas que trabalham por meio de métodos públicos e privados. Rane (2010), ainda afirma que quando a solução SaaS é projetada para comercialização, deve garantir ao cliente a confiabilidade dos dados, já que esse software é único para todos os usuários. Porém as informações de cada usuário são utilizadas de forma particular e individualizada. Para haver uma segurança maior neste software os dados que trafegarem na rede deve utilizar chaves criptográficas a partir de 64bits, afinal, as inferiores não

16

garantem a confiabilidade das informações devido à fragilidade e facilidade de quebras dos protocolos de criptografia.
Outra desvantagem esta na migração do conteúdo (dados). Se o contratante, por exemplo, resolver mudar de contratado por qualquer motivo relevante que seja, deverá exigir a transferência dos seus dados, e o contratado deverá assegurar ao contratante a liberdade de migração do conteúdo para um formato externo, assim como a funcionalidade dos dados para outra aplicação, no momento que o contratante julgar necessário. Quando o aplicativo é bem gerenciado não há problema durante a exportação desses dados. Porém, a dificuldade pode ser observada também de uma maneira diferente. O contratado pode, por exemplo, desenvolver uma solução de serviço que ofereça ao contratante a possibilidade de em algum momento compartilhar informações com outras aplicações, assim como um software que permita uma maior combinação com as aplicações do contratante, esse serviço do contratado será de interesse do contratante, ganhando um destaque diferencial em relação aos serviços do concorrente. (MOTA,2009)

2.6

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

duas categorias: serviços de linha de negócios e serviços orientados a cliente. Os serviços de linha de negócios, conhecidos como software vertical, são fornecidos às empresas e organizações de todo tipo. Os softwares verticais são aplicações que contém conhecimentos de uma ou mais especialidades. A venda é feita sob a forma de encomendas e geralmente são comercializados a setores específicos. São aplicativos de interesses grandes e personalizáveis com o intuito de facilitar processos de negócios. Já o software horizontal é de uso geral, a distribuição geralmente é feita em larga escala e a preferência dos consumidores se dá pela marca e reputação das empresas. Ou seja, esses softwares servem para qualquer segmento de mercado. O software horizontal também conhecido com serviços orientados à cliente é um serviço oferecido a todos os meios. Esse tipo é normalmente vendido sem custo e financiado por anúncios.

17

2.7

SAAS CORPORATIVO Os softwares corporativos são utilizados exclusivamente pelas

empresas. A maioria das organizações sente a falta de algumas informações que não são integradas com outros aplicativos da empresa, o que torna difícil a localização de tais dados. Na atualidade, a web se tornou um meio eficaz para o fornecimento de informações. A grande maioria das organizações busca obter maior eficiência operacional de seus dados, indo de encontro à tendência de alterar o local da utilização dos softwares. O aparecimento da solução SaaS trouxe melhores oportunidades para o negócio 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, bancário, entre outros. É uma vantagem para as empresas oferecerem esses serviços a outras empresas, principalmente se o software desenvolvido for de qualidade. Segundo Chong & Carraro. (2006), “os princípios que permitem à empresa utilizar os benefícios da Cloud também admitem oferecer serviços à mesma”. De acordo com Wething (2008), “um software do tipo coorporativo distribuído como SaaS representa serviço de integração significativa". Ou seja, a integração dos dados não deixa de ser um serviço complexo para incorporar os dados ao SaaS. Acredita-se que o futuro do software corporativo não se apoiará simplesmente em recursos instalados na máquina local ou na internet, existindo, assim, uma relação de integração entre ambas.

18

3 ARQUITETURA SAAS
Vários tipos de componentes de softwares, aplicações e frameworks podem ser aplicadas no modelo de desenvolvimento SaaS. O aparecimento de componentes e aplicações modernas e novas tecnologias reduz drasticamente o tempo hábil de mercado e os valores agregados para a conversão de um produto do modelo tradicional em uma solução SaaS. Segundo Rittinghouse (2010), a arquitetura SaaS é classificada em 04 (quatro) níveis de maturidade em que os atributos chaves podem ser configurados. Estes níveis são:  Maturidade da Arquitetura Nível 1 – Ad-hoc/custom: cada cliente possui uma única e customizada versão do aplicativo de hospedagem. O aplicativo roda no servidor de hospedagem. Migrar um aplicativo tradicional ou um cliente-servidor para este nível de SaaS requer maturidade para mais um esforço de desenvolvimento, reduzindo custos operacionais por consolidar o servidor de hardware e administração. Motta (2009) defende que nesta etapa o atendimento do cliente é diferenciado e o software é individualizado, porém, o custo com este serviço é bastante alto, pois cada usuário, de forma particular, utiliza o aplicativo hospedado em sua versão personalizada, e utiliza no aplicativo a solicitação nos servidores do host.  Maturidade da Arquitetura Nível 2 – Configurabilidade: o segundo nível de maturidade SaaS fornece uma maior flexibilidade de programa por meio da configuração meta data. Neste nível, muitos clientes podem usar separadas instâncias para a mesma aplicação, permitindo que o vendedor possa ter várias opções de configuração a partir das necessidades dos clientes. Além disso, permite que o vendedor alivie a carga de manutenção por ser capaz de fazer atualizações com base em um código comum.

19

 Maturidade da Arquitetura Nível 3 – Eficiência Multilocatária: o terceiro nível adiciona o caráter de locação múltipla ao segundo nível. Isto resulta em um simples programa que tem como exemplo a capacidade de servir a todos os clientes. Esta abordagem permite maior eficiência no uso de recursos, sem que haja qualquer diferença aparente para o usuário final. Entretanto, ultimamente este nível é limitado em um escala massiva.  Maturidade da Arquitetura Nível 4 – Escalabilidade: a escalabilidade é adicionada pelo o uso de uma arquitetura em multicamadas. Esta arquitetura é capaz de suportar uma carga de exploração equilibrada, por exemplo, aplicações idênticas rodando em um número 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 níveis que presenciamos de maturidade neste estudo são características importantes do modelo SaaS, trazendo o pensamento de que o nível mais apropriado de maturidade seja o último. Porém, deve-se levar em consideração que o processo de maturidade acontece através de uma sequência contínua, em que de um lado se dá os códigos e os dados separadamente e do outro lado dados e códigos compartilhados. Na próxima seção será visto o ciclo de desenvolvimento SaaS, passando por todos os seus processos, desde os conceito de multiusuário (multi-tenant) até o ciclo de vida do desenvolvimento.

3.1

CICLO DE DESENVOLVIMENTO As aplicações SaaS que são disponibilizadas para os clientes do

serviço são aplicações de software que um fornecedor SaaS desenvolveu, de acordo com padrões específicos (incluindo protocolo de rede, serviço,

20

protocolo, segurança, transporte, etc.). Estes softwares podem ser publicados em um servidor na Internet. Além disso, o usuário não precisa adquirir o certificado do software, apenas alugar o módulo de função do software, de acordo com a demanda física própria, e pagar de acordo com o tipo de serviço, número e tempo de uso. Conforme estas características, o quadro dos aplicativos SaaS deve ter estruturas como serviço de camada de transporte, serviço de camada de programação, camadas de tecnologias de serviços, camadas de serviços e dados, e serviços da camada de gestão, afirma He (2010). Na próximas linhas será descrito um estudo mais específico.  Serviço de camada de transporte: garante o retorno da informação sobre a exatidão de solicitações de usuários e aplicações, através do uso de SOAP, Web Service, XML e alguns protocolos correspondentes de rede e segurança.  Serviço de camada de programação: possibilita o usuário escolher o serviço que a plataforma oferece, de acordo com o próprio pedido. Nesta instância o cliente pode parametrizar a aplicação, definir os campos, a forma do menu, o fluxo de trabalho, as propriedades, entre outros.  Camadas de tecnologias de serviços: tal camada tem como função, manter o contato do cliente com o fornecedor da aplicação, ou o prestador de serviço, para assim, se dar as negociações do tipo de serviço, lançamentos dos serviços, integração e etc. Esta camada fornece serviço API (Application Programming Interface) ou web.  Camadas de serviços e dados: fornece API e serviço web especial para a transferência de formação superior (pequenas, médias ou grandes empresas). Ele é implementado pelo pacote de processos básicos de acordo com o resumo da demanda do mercado. Portanto, esta camada expressa a diferença entre os tipos de aplicações SaaS, como SBM, CRM, RH ou ERP, entre outras.

21

 Serviços da camada de gestão: oferece três maneiras de gerenciar dados de múltiplos usuários, 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 três características: cliente construído, elasticidade e multiusuários eficientes. O conceito de elasticidade se dá quando uma alocação 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 também significa que um aplicativo pode ser escalado quando são adicionados novos usuários e quando os requisitos do aplicativo mudam. O modo de desenvolvimento SaaS de multiusuário eficiente possui diferenças significativas com relação ao desenvolvimento tradicional de softwares, dividido em duas partes: isolamento de dados e implementação da interface. O autor ainda afirma que os dados para aplicação de um único usuário legado são fixados sobre a mesma base de dados, sem os problemas que envolvem o isolamento dos dados. Há três 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 descrição dos bancos:  Banco de dados separados: segundo Wolter et al. (2006), geralmente todos os inquilinos compartilham os recursos da máquina (e da aplicação) de um mesmo servidor, mas as informações de cada

inquilino são diferentes, e permanecem isoladas dos dados pertencentes a outros inquilinos. Os metadados recebem a incumbência de fazer as associações corretas dos bancos de dados para os seus respectivos inquilinos. Quem é responsável por garantir a integridade das informações para que os inquilinos não acessem os dados de outros são a prerrogativas de gerenciamento de segurança 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 informações de múltiplos inquilinos numa mesma base de dados, em que os inquilinos irão possuir um conjunto de tabelas, que serão agrupadas em um esquema especifico para cada inquilino, conforme mostra a Figura 8.

23

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

O complemento do desenvolvimento do modelo SaaS se dá com a implementação da interface. Segundo He (2009), em uma aplicação tradicional a interface do sistema sempre atende aos requisitos básicos para o usuário, pois a interface é feita sob medida e implantada de acordo com a exigência do usuário. No modelo SaaS as aplicações utilizam o mesmo conjunto de interface, não podendo atender todas as necessidades dos usuários. Assim, os recursos configuráveis das interfaces das aplicações SaaS não podem ser ignorados. A página pode ser dividida em menu do sistema e os elementos da página, em que ambos devem ser dispostos a receber personalização de seus clientes. O modelo SaaS também 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 soluções partilham no momento de definição de qual tipo de aplicativo será desenvolvido para o fornecimento do serviço que será proposto para o usuário 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 níveis: prevendo, avaliação da plataforma, planejamento, inscrevendo, desenvolvimento e operações. Estes níveis descrevem as melhores práticas no momento da decisão da criação de um novo aplicativo para o fornecimento de serviço. Nas próximas linhas mais detalhes serão abordados.

1. Prevendo: nesta fase do desenvolvimento o fornecedor procura identificar as novas tendências e as oportunidades de negócio com o objetivo de sempre expandir a quantidade de clientes para chegar ao conceito de cauda longa, definindo, assim, as visões e o escopo do serviço SaaS.

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

25

(2011) como crítico para o sucesso da aplicação, uma vez que o provedor pode influenciar no nível 1 (um), se o provedor de nuvem não possuir as características necessárias para alocar o tipo de serviço definida na primeira fase, toda a arquitetura do serviço deverá se adaptar ao provedor.

3. Planejamento: após identificação plataforma de nuvem viável para a construção do serviço de SaaS, a fase de planejamento ajudará a traçar o curso de ação para uma entrega previsível do serviço. Planejamento depende muito do tipo de serviço e da cultura organizacional. O rigor das atividades e os resultados finais dependem da complexidade e do tamanho do serviço. As atividades nesta fase são 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 produção, implantação e operacionais do serviço que está sendo planejado. Os arquitetos e profissionais de TI irão revisitar os modelos de implantação, esquemas, modernização, processos de apoio, continuidade de negócios e recuperação de desastres.

5. Desenvolvimento: ocorre através da construção dos artefatos e elaboração da documentação, podendo o projeto sofrer alterações a partir da descoberta de novas funcionalidades e da alocação de recursos. O escopo de funcionalidade e o cronograma determinam a granularidade e número de interações.

6. Operações: nesta etapa acontece o processo de implementação do aplicativo, integração e personalização dos aspectos operacionais da plataforma no contexto do serviço 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 relação ao fator “gerenciamento do ciclo de vida da aplicação”, as empresas precisam desenvolver mais o setor de gerenciamento da informação para manter e operar as aplicações de SaaS. Precisam conhecer o ambiente do cliente, prezar pelas ações operacionais no sentido de resolver problemas de segurança, performance, disponibilidade, entre outros. O objetivo é que realmente os fornecedores de SaaS cuidem da gerência de TI, pois a empresa não possui mais a aplicação.

As próximas seções comentarão sobre a segurança no ambiente SaaS.

3.2

SEGURANÇA SAAS Segundo Motta (2009), um dos maiores desafios para os fornecedores

de SaaS é a fabricação de sistemas que possuam mais segurança, que necessite de menos atualizações e possam permitir um gerenciamento de segurança com problemas reduzidos. Os autores Rittinghouse & Ransome (2010) transcrevem 07 (sete) questões de segurança para a discussão direta com os fornecedores de Cloud Computing e SaaS. Esta questões foram enumeradas por analistas da empresa Gartner (http://www.gartner.com), sendo abordadas nas próximas linhas:

1. Acesso privilegiado: o autores apontam os tipos de argumentações que devem ser realizadas ao fornecedor com relação a quem possui acesso especializado aos dados, assim como as possíveis contratações de administradores.

2. Conformidade com as regulamentações: o autores enfatizam que o cliente deve certificar que o fornecedor estará disposto a se submeter a auditorias externas e possuir certificações de segurança.

27

3. Localização dos dados: o cliente deve questionar se o fornecedor permite controles sobre a localização dos dados.

4. Segregação dos Dados: o cliente deve questionar ao fornecedor SaaS se a criptografia está presente em todas as etapas da comunicação, e se tal funcionalidade foi testada e implementada por profissionais confiáveis.

5. Recuperação dos dados: o cliente deve questionar sobre a recuperação dos dados, caso ocorra possíveis eventualidades,

catástrofe, e em quanto tempo o fornecedor disponibilizará os dados de volta.

6. Apoio Florence: o cliente deve questionar se o fornecedor possui, métodos para ajudar em uma possível investigação.

7. Viabilidade em longo prazo: o cliente deve questionar ao fornecedor sobre suas políticas de entrega dos dados caso a empresa venha a sair do ramo de negócio, assim também como qual tipo de formato tais dados serão entregues.

Vários outros autores falam sobre estudos de grandes empresas no ramos de segurança 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 equívocos que acontecem na adoção da solução SaaS, tais como gerenciamento imaturo de identidade, a

inconsistência nos padrões de cloud, sigilo, a grande disponibilidade de acesso, que traz o aumento de riscos, e a localização difusa dos dados. Todos estes estudos encontrados no decorrer da pesquisa levam a visualizar a inconsistência do modelo, mostrando, assim, a necessidade cada vez maior da implementação de um gerenciamento consistente. O capitulo 3 abordará as vulnerabilidades e riscos que assolam o modelo SaaS.

28

3.3

GESTÃO DE RISCOS SAAS Segundo Ramos (2007) em um artigo para web, a gerência de riscos é

um processo que deve ser executado continuamente e seus gestores têm responsabilidade direta na condução do processo. Ramos ainda afirma que a gerência 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 gestão eficaz dos riscos na plataforma SaaS implica na identificação de ativos de tecnologia, identificação de dados e suas ligações com os processos de negócio, aplicações e dados e a atribuição de propriedade e responsabilidades privativas de liberdade. As ações devem

incluir a manutenção de um repositório de ativos. Os proprietários têm autoridade e responsabilidade para os ativos de informação, incluindo os requisitos de proteção, como confidencialidade, integridade, disponibilidade e controles de privacidade. Um processo formal de avaliação de risco deve ser criado e os recursos de segurança ligados à continuidade dos negócios. Gruman & Pita. (2007) também afirmam que os clientes devem exigir dos fornecedores de SaaS os mesmos requisitos de auditoria e controle que exigiriam de qualquer terceiro, incluindo cláusulas de segurança 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

e

fornecedores. O primeiro usa o serviço de aplicação previsto por este último. Cliente SaaS geralmente usa um multi-level (multi-lateral) modelo de segurança para acessar remotamente o serviço, por exemplo, uma empresa terá diferentes usuários que acessam o software com privilégios diferentes. Um serviço de SaaS pode ser oferecido a um único cliente, mas muitas vezes é projetado com uma arquitetura multi-tenant, em que o mesmo serviço é oferecido para vários clientes. Embora algumas aplicações SaaS pareçam um

29

pedaço monolítico de software para o cliente, ele pode realmente ser implementado com uma arquitetura multi-fornecedor. O fornecedor poderá hospedar seus aplicativos em seu próprio 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 segurança de um Serviço SaaS, deve-se considerar quatro tipos de ameaça: a interação clientefornecedor, as internalizações cruzadas entre diferentes clientes para o mesmo fornecedor, a interação entre o provedor de SaaS e os sub fornecedores e, finalmente, atacantes externos que podem segmentar qualquer parte da solução SaaS. Assim, neste tópico se estudará as vulnerabilidades e as classificações da seguinte maneira: mau comportamento do serviço,

computação confiável, violação dos dados dos clientes, compartilhamento de recursos, ameaças a rede e autenticação.

3.5

MAU COMPORTAMENTO DO SERVIÇO

Um provedor pode adulterar dados, ações ou eventos relacionados à execução de aplicativo SaaS para esconder violações das condições contratuais. Como por exemplo, um provedor pode criar arquivos de log ou adulterar os sistemas de auditoria para esconder violações de SLA, QoS ou acordos que foram feitos isoladamente, com intuito de prejudicar diretamente o serviço e o contratante.

3.6

COMPUTAÇÃO CONFIÁVEL

Segundo artigo escrito por Brodkin (2010) para a revista NetworkWorld (http://www.networkworld.com), os fornecedores de SaaS tendem a argumentar que eles são mais capazes de proteger os dados que um típico cliente, e que a segurança SaaS é realmente melhor do que a maioria das pessoas pensam. Mas na realidade os clientes não se deixam levar sobre esta afirmativa porque

30

os fornecedores de SaaS tendem a ser bastante reservados sobre seus processos de segurança. O autor ainda afirma que muitos dos prestadores de serviços em nuvem liberaram poucos detalhes sobre seus centros de dados e operações, alegando que comprometeria a segurança. Um contratado (provedores) pode prestar serviço não confiáveis para o cliente utilizando de preceitos mal-intencionados. Além disso, um provedor pode realizar ações não autorizadas/solicitadas representando clientes. Por exemplo, pensando em um serviço que pode fornecer e comercializar informações, o provedor poderia conspirar com outro cliente e modificar o serviço para tornar os resultados falsificados, ou apenas um subconjunto dos resultados corretos para beneficiar tal cliente. Um cenário semelhante poderia envolver um serviço que executa elaborações úteis para a análise de protótipo, assim, o provedor poderia modificar o serviço de forma aleatória tornando os resultados errados para atrasar o processo de desenvolvimento de um cliente. Dadas essas ameaças, a solução SaaS deve esta equipada com funções que verifiquem integridade, alerta Agrawal et al. (2011).

3.7

VIOLAÇÃO DOS DADOS DOS CLIENTES

Um contratado (provedor) pode executar ações enquanto os dados de uma aplicação são acessados ou armazenados. As possíveis ameaças que atuam nesta etapa são de leituras não autorizadas e as modificações dos dados podem forjar informações e até mesmo excluí-las, trazendo, assim, uma alta responsabilidade para tais contratados (provedores). Um usuário malintencionado pode usar as vulnerabilidades de aplicativos para artesanato, com parâmetros que ignoram as verificações de segurança e acessam dados confidenciais de outros inquilinos. Intrusão específica pode levar a segregação de dados do fornecedor de uma solução SaaS em uma implantação 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 Injeção SQL  A validação de dados  Armazenamento inseguro

3.8

COMPARTILHAMENTO DE RECURSOS

A solução SaaS possui alguns recursos que são compartilhados entre vários clientes, tais recursos podem ser apenas de hardware (em

implementações baseadas em virtualização), bem como a distribuição de serviços de armazenamento, multiusuário de software, e até mesmo processos de aplicação (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 proteção, 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 eficácia dos ataques comuns tradicionais, como o Sequestro de Sessão, Cross-site Scripting e SQL Injection.

3.9

AMEAÇAS A REDE

O SaaS é remoto por definição, portanto, requer comunicações baseadas em rede, na forma de protocolos. O provedor configura um aplicativo

32

para usar um protocolo inseguro. Basicamente o aplicativo passa as informações entre o cliente e o servidor com um protocolo que não assegura a confidencialidade ou a Integridade. Isto ocorre em dois contextos principais: como usuário e como administrador. Aplicações que usam protocolos inseguros, como Telnet para remoto acesso, FTP para transferência de arquivos, POP e IMAP para E-mail, e HTTP para acesso web irão expor seus dados para alguém ao longo do caminho da comunicação, alerta Cox (2010). Pensar na adoção do modelo SaaS leva o contratante (cliente) à migração 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, várias questões de segurança. As ameaças comuns voltadas à rede como sniffing, flood e

tampering afetam diretamente a confidencialidade, integridade e disponibilidade da comunicação, uma vez que o serviço é disponibilizado através da internet.

3.10 AUTENTICAÇÃO

Henrique (2011) descreve um estudo da Forrester Research que pesquisou entre 306 (trezentas e seis) organizações que migraram para o uso de serviços baseados na nuvem, tal estudo chegou à conclusão que mais da metade (54%) das companhias entrevistadas passaram por problemas de segurança no último ano. O autor ainda afirma que de acordo com a pesquisa, mesmo com o aumento significativo de soluções de segurança, a grande maioria das empresas continua usando o tradicional método de autenticação login e senha para verificar a identidade do usuário, em vez de adotar medidas mais fortes. Para um aplicativo SaaS ser acessado via rede, o controle de acesso é obrigatório e não pode ser baseado em endereços de rede, devido a possíveis falsificações. Nem todas as arquiteturas de autenticação são adequadas para um controle de acesso SaaS, por exemplo, compartilhar o mesmo mecanismo de autenticação entre aplicações SaaS e as baseadas em servidor deve ser absolutamente evitado, pois há o risco de um fornecedor se apoderar de uma

33

credencial de autenticação, válida não apenas na aplicação SaaS, mas também para outras aplicações de clientes não hospedados neste provedor. Segundo Cox (2010), a autenticação e autorização são funções que devem ser separadas a partir da lógica de aplicação quando se deslocam para o paradigma SaaS. O autor ainda afirma que elas devem se tornar autossuficientes e atuar como componentes externos da aplicação 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 autenticação SaaS, contextualizam Agrawall et al. (2011). Na próxima seção será

apresentado a solução proposta para o modelo de gerenciamento de segurança para a solução SaaS.

34

4 GERENCIAMENTO NO CLICO DE VIDA DE DESENVOLVIMENTO SAAS
Segundo Moreira et al. (2011), o gerenciamento de um ambiente na nuvem possui características da plataforma diferentes SaaS deve dos ambientes no comuns. momento O do

gerenciamento

começar

desenvolvimento do aplicativo, e é nesta etapa que as ameaças devem ser identificadas e os riscos analisados para uma possível implementação de controles específicos que tratem estas ameaças. Rittinghouse & Ransom. (2010) citam fases de boas práticas que devem ser religiosamente implementadas no ciclo de vida do desenvolvimento de aplicativos SaaS, que são:

1. Investigação: nesta fase todos os processos e metas devem ser documentados nas políticas de segurança. 2. Analise: analisar cuidadosamente as políticas de segurança, examinar questões legais, executar as análises de riscos, assim como as atualizações das novas ameaças. 3. Projeto Lógico: nesta fase se deve projetar um plano de respostas a incidentes e desastres, assim como não descartar a viabilidade de uma possível terceirização do projeto. 4. Projeto Físico: nesta fase se deve analisar tecnologias para auxiliar no projeto de segurança, e criar medidas de segurança para suportar novas soluções. 5. Implementação: nesta fase se deve possuir um pacote testado para implementar a gestão de segurança da aplicação, analisar as premissas de compra ou desenvolvimento de soluções para ajudar em tal gerenciamento. 6. Manutenção: esta fase se estende por todo o processo em que se deve monitorar, modificar, testar, reparar e atualizar as respostas às mudanças das ameaças.

35

No modelo de gerenciamento no ciclo de vida do desenvolvimento, o código do aplicativo também deve ser escrito de maneiras mais consistentes, para assim, facilitar o processo de auditabilidade e reforço do código. Todos os quadros e módulos do aplicativo devem ser testados para os problemas de segurança com testes de penetração interna e externa antes de serem implementados. A implantação de padrões e requisitos de segurança com base na classificação dos dados não deve ser deixada para traz. Assim, a implementação do gerenciamento da segurança no principio do desenvolvimento, pode minimizar danos futuros.

4.1

GERENCIAMENTO DE IDENTIDADES As solução SaaS é uma arquitetura moderna baseada nos conceitos de

aplicação web, que possibilita a comunicação entre o contratante e o contratado, sendo este último quem utiliza as soluções de criptografia para os tráfegos de dados. A comunicação que se dá através de canais públicos que facilitam o acesso e a busca dos clientes por soluções, que sejam capazes de integrar em seu ambiente de trabalho padrões de gestão de identidade, e a existência de outros em busca de provedores de SaaS que possam garantir a segurança dos seus dados, traz uma dicotomia que passa a exigir de forma direta que a solução SaaS seja capaz de tratar e/ou manusear modelos de autenticação internas, autorização e federação, em que para este último é necessário que o serviço possua pontos de integração, como repositórios internos para aqueles que não possuem produtos de gerenciamento de identidade, de acordo com Mather et al. (2009). Esta monografia irá propor um modelo de gerenciamento para possíveis estudos e implementações.

4.2

MODELO DE GERENCIAMENTO DE USUÁRIO PARA AUTENTICAÇÃO CENTRALIZADA

36

O método mais viável de autenticação é quando o fornecedor SaaS mantém um banco de dados independente da administração de qualquer cliente, conforme apresentado na Figura 10.

Figura 10 - usuário e permissões contidas em banco de dados independente. Fonte: Software (2008).

A Figura 10 demonstra um exemplo geral de um usuário em um site onde o mesmo tem suas permissões contidas em um banco de dados dentro de uma pilha de SaaS. Esta metodologia é comumente desenvolvida dentro de uma arquitetura SaaS devido à simplicidade de implementação. No entanto, é importante fazer uma distinção entre autenticação e autorização para que os usuários que chegam possam ser canalizados através de um módulo de autorização unificada. Assim, a Figura 11 apresenta um modelo de caso de uso expandido e um diagrama de sequência para tal requisito que envolverá apenas o usuário final e o gerente da solução SaaS.

37

Figura 11 - Modelo de gerência de usuário

A Figura 11 demonstra o diagrama de caso de uso do modelo de gerenciamento, ressaltando apenas os atores, usuário final e gerente SaaS, em que o gerente possui a capacidade de inserir, remover, alterar e buscar os usuários, e o ator usuário após a autenticação possui privilégios regulares sobre a aplicação. Já a Tabela 1 demonstra o caso de uso expandido do gerenciamento de usuário. Práticas exercidas pelo gerente SaaS.

Caso de uso: Gerência de usuário

1. Inserir usuário

O usuário informa ao sistema os dados para cadastro: nome, senha, login e tipo pessoa, caso o usuário for Pessoa Física (endereço, telefone, RG, órgão emissor, profissão); caso o usuário for Pessoa Jurídica (tipo pessoa física, Nome Fantasia, CNPJ, Inscrição Estadual).

38

2. Buscar usuário O ator acessa o sistema, se identifica, acessa a área Buscar Usuário. Informa os dados do tipo de usuário e confirma a ação

3. Alterar usuário

O usuário informa ao sistema novos valores os dados e confirma a ação.

4. Excluir usuário  O sistema apresenta uma lista de usuário separado pelo tipo ordenado, pelo nome.  O usuário seleciona um usuário da lista para exclusão.

5. Inserir Permissão

O gerente SaaS seleciona no sistema o tipo de permissão que será dada aos usuários, ou utiliza as permissões de negócio uma vez se houver federação SSO

6. Buscar Permissão  O sistema apresenta formulário com nome | CPF para pesquisar dados da permissão.  O usuário digita o nome | CPF e seleciona a opção Ok.  O sistema apresenta dados dos tipos de permissão.  O sistema utiliza as permissões de negócio caso a operação seja voltada a federação SSO

7. Alterar Permissão

39

O usuário informa ao sistema novas permissões para o usuário, pode escolher um novo papel para o usuário ou um novo módulo do sistema.

8. Remoção da Permissão  O sistema apresenta uma lista de permissão ordenada por tipo.  O usuário seleciona um elemento permissão da lista para exclusão.

Tabela 1- Gerência de usuário

A Figura 12 apresenta um diagrama de sequência onde o ator gerente esta à inserir um usuário que ficará armazenado em um bando de dados independente, e após todas as verificações necessárias, o mesmo recebe na página de gerenciamento a mensagem de confirmação do cadastro.

40

Figura 12 - Diagrama gerenciamento de inserção de cadastro

O próximo diagrama de sequência, Figura 13, mostra outra prática do gerente SaaS, em que o mesmo acrescenta ao usuário permissões para a formulação do ambiente após a autenticação do usuário. Esta prática apenas acontece caso o gerenciamento não adotar outras soluções como a de Federação SSO (Single SignOn), que será vista com mais detalhes.

41

Figura 13 - Diagrama de sequência de gerenciamento de permissões.

Após a visualização dos feitos do gerente de SaaS,

serão

apresentados os processos de autenticação do usuário final. A Tabela 2 apresenta o modelo de caso de uso expandido da autenticação do usuário final. Práticas para um melhor gerenciamento de autenticação do usuário final.

42

Caso de uso: Autenticar Usuário

Ator:

Usuário Final

Interessado:

Usuário Final

Pré-condições:

Os devidamente

usuários

devem

estar para

cadastrados,

assim, poderem fornecer login e senha Pós-condições: Autenticação no sistema

Responsabilidade:

Autenticar o usuário

Descrição:

Demonstra como um usuário pode obter acesso ao sistema.

Variações tecnológicas:

A autenticação deverá ser efetuada por meio de formulários que utilizam certificação digital utilizando criptografia com chaves assimétricas. O mesmo será instalado no servidor que utilizará de protocolos HTTPS, assim, quando seus o usuário dados for

autenticado

estarão

criptografados .

Fluxo Principal:

O usuário acessa a página principal do sistema e localiza o formulário de login, preenche os campos e submete os dados para o sistema. O usuário é redirecionado

43

para a página inicial do sistema.

Autenticar o usuário

Ações do ator

Ações do Sistema

1. O usuário acessa o sistema 2. O usuário preenche os dados de login e senha

1. O sistema exibe a tela inicial 2. O sistema processa os dados do usuário e redireciona para a sua página inicial 3. O sistema armazena na base de dados a data e a hora do acesso.

Tratamento de Erros:

1. Senha ou login inválidos O usuário é informado que o login e a senha são inválidos 2. O usuário não pode logar no sistema O usuário é informado que o sistema esta bloqueado, o sistema exibe uma mensagem de erro e retorna o usuário para o passo 2(ações do ator)

Tabela 2- Autenticar Usuário.

O diagrama de sequência abaixo demonstra a solicitação de autenticação do usuário final para acessar a plataforma SaaS.

44

Figura 14 - Diagrama de Sequência de autenticação do usuário final.

4.3

MODELO DE GERENCIAMENTO DE USUÁRIO PARA AUTENTICAÇÃO DECENTRALIZADA Uma solução complementar ao estudo visto no tópico 3.2 é a

implementação de um modelo no qual os usuários possa autenticar diretamente de seu sistema de autorização. Geralmente, isso significa que o usuário está logado em um domínio 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 políticas de segurança necessárias em torno de

gerenciamento de identidade com o benefício adicional de que os recursos e os riscos associados ao gerenciamento de identidade estão sendo transferidos para o cliente. A solução que se aplica a tal proposta é possível com o uso da federação Single Sign On (SSO), que pode ser implementada através de token ou afirmações (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 organização, é SAML que fornece o mecanismo para que as informações de identidade sejam transmitidas com segurança para o provedor de SaaS. Nas próximas linhas será visto um cenário do uso de Single SignOn (SSO) que pode utilizar o cenário de chave de validação com cenário chave titular (HOK) que usa tokens SAML com o método de confirmação em vez do método de confirmação ao portador. Tokens SAML HOK contém 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 (também conhecida como uma chave simétrica) ou um certificado X.509 com uma chave pública (também conhecido como uma chave assimétrica). No caso de uma chave compartilhada, a chave é criptografada usando a chave pública, destinada ao prestador de serviços de negócio de modo que apenas o serviço de negócio 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 cópia da mesma chave na resposta WS-Trust para o cliente solicitante. Isto é necessário porque, caso contrário, o cliente não 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 solicitação SOAP. A solução SaaS pode validar a HOK propriedade token, extrair a chave criptografada compartilhada e usá-lo para verificar a assinatura digital. O usuário então utiliza tokens SAML para acessar a solução SaaS. A empresa prestadora de serviços valida os tokens SAML e afirma a identidade e os atributos do usuário com base na relação de confiança entre o prestador e os STS. Os tokens SAML recebidos são considerados válidos se os certificados de assinatura de token são confiáveis pelo provedor de serviços de negócio e se o tempo de expiração dos tokens é inferior ao tempo de provedor de serviços de negócios local.

46

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

A Figura 15, mostra um usuário tentando acessar um provedor SaaS em que o mesmo irá utilizar um token SMAL HOK criptografado através de STS. Esta autenticação se dará no diretório do usuário através de uma chamada SOAP que o mesmo diretório irá responder a autorização e confirmação de autenticação, assim, quando os tokens SAML recebidos são considerados válidos e os certificados de assinatura de token são considerados confiáveis pelo provedor SaaS, a autorização ao serviço se dá por completa.

4.4

MODELO DE GERENCIAMENTO DE LOG Devido à utilização da Internet pública, o movimento de dados da

plataforma SaaS para o cliente é quase idêntica aos desafios de segurança que se colocam em outros modelos de negócios, tais como o modelo ASP. ASP e SaaS usam a Internet sem garantia pública para transmitir dados. Estes desafios de segurança são abordados por abraçar três conceitos principais:  Não-repúdio - Destinatário dos dados tem provas de que os dados foram originados a partir do provedor SaaS.

47

 Confidencialidade - Os dados só podem ser visualizados pelo destinatário.

 Integridade - Os dados não podem ser alterados sem detecção.

Estes três conceitos devem ser tratados por igual, como um grupo, já que, se a solução for dada para apenas um caso em especifico, será muito abrangente e as outras não serão tratadas nem gerenciadas. Considera-se uso de ferramentas como SSL ou criptografias TLS tratando o tráfego entre o servidor Web e o cliente, já que estes protocolos são projetados para evitar a espionagem, adulteração e falsificação. Assim, um processo automatizado deve ser construído para o gerenciamento dos logs de auditoria diária. Devido à grande quantidade de acesso que supostamente um aplicativo SaaS possui e a diversidade de meios eletrônicos para tal acesso, é importante manter registros de provas que demonstrem a origem de todas as entradas, como alterações, adições, exclusões e aprovações. O log de auditoria deve ser criptografado e mantido em um segmento de rede que os engenheiros de sistemas não 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 usuário (contratante do serviço) e o gerente SaaS (contratado) com suas respectivas funções 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 usuário diante do log do sistema. O gerente pode configurar o log, visualizar e emitir o relatório do log, já o usuário pode apenas visualizar. Este modelo de gerenciamento possibilita ao gerente de SaaS tentar garantir a integridade do log. O gerenciamento da entrada e saída do usuário dos sistema, e o que o mesmo faz que não esteja de acordo com a regra de negócio, sempre deve ser armazenado de forma segura para facilitar uma possível investigação e o uso da não-repúdio. O gerenciamento do log deve ocorrer no início da conexão do cliente ao aplicativo, para, assim, possibilitar a identificação de um possível intruso, ou, caso algum ataque aconteça, saber se o usuário agiu com má intenção. 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 usuário, armazenando o horário e a data em que houve a autenticação no sistema. O log principal de acesso, e o modulo, pode ser ativado devido às regras de negócio, e em cada empresa, sempre as funções

50

de gerenciamento devem ser ativadas, mesmo se a empresa não possua regra de negócio definida. Falar de gerenciamento de log e não especificar um modelo de auditoria tornaria todo o processo ineficiente. Na atualidade, no mercado de serviço 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 relatório confiável de suas práticas 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 substituída por SSAE 16. SSAE 16 é a próxima geração de AICPA, normas para elaboração de relatórios sobre os controles nas organizações de serviços, incluindo software como prestadores de serviço, nos Estados Unidos. SSAE 16 vai além do SAS 70, não só verificar os controles e processos, mas também exigir uma declaração escrita sobre a eficácia de design e operacional dos controles sendo revisados. Além disso, SSAE 16 é adotada e fortemente alinhada com as Normas Internacionais para trabalhos de asseguração (ISAE) 3402, o novo padrão de auditoria internacional para prestadores de serviços. Ambas as entidades (AICPA e ISAE) alinhadas cada um com seus respectivos padrões.

51

5 CONCLUSÃO
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 questão envolve dados confidenciais, tudo muda de história, uma vez que informações de grandes empresas utilizam canais que envolvem protocolos web para acesso, fazendo da segurança o fator primordial para este novo paradigma. Este trabalho de conclusão de curso propôs um estudo de revisão bibliográfica sobre SaaS, ressaltando seus aspectos econômicos, teóricos, de desenvolvimento, segurança e vulnerabilidades que assolam tal modelo, assim como mostrou subsídios para ajudar na construção de um modelo de gerenciamento de identidade. A revisão foi desenvolvida com base em pesquisas bibliográficas, que envolveram livros, artigos, publicações e sites. A revisão de literatura abordou conceitos fundamentais para a compreensão da plataforma SaaS mostrando as melhores práticas que devem ser utilizadas no processo de adoção desta plataforma, ajudando para demonstrar um método de autenticação gerenciada e boas práticas para o armazenamento e gerenciamento dos logs para possíveis auditorias. Na proposta do modelo de gerenciamento foi utilizada a ferramenta UML para a manipulação de diagramas, como os de caso de uso e o de sequência, para os processos de gerenciamento de autenticação e dos logs, sendo visto também os conceitos de criptografia Tokens SAML para o modelo de autenticação e a proposta de um novo modelo de auditoria SSAE 16 Contudo, este estudo mostrou formas de como se prevenir de possíveis ameaças antes da implementação de ferramentas para suporte, uma vez que a segurança no modelo SaaS deve ocorrer no momento da escolha do fornecedor. As especificações da documentação SLA, que possui as diretivas acordadas para o uso e fornecimento do serviço, mostrou meios para o gerenciamento das principais rotinas de um sistema SaaS. Pensando nos trabalhos futuros, sugere-se os seguintes temas:

52

 Promover a implementação 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 REFERÊNCIAS

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 automático de aplicações e plataformas de trabalho em nuvens computacionais. Science And Technology, 2010. BRIVO. SaaS — TCO. System. [S.l: s.n.]. , 2009

BRODKIN, J. 5 questões a considerar sobre segurança em SaaS. Disponível 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 Serviço (SaaS): uma perspectiva corporativa. Disponível em: <http://msdn.microsoft.com/pt-

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

CHONG, FREDERICK; CARRARO, G. Estratégias de Arquitetura para Cauda Longa (Long Tail). Disponível 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 relação entre Computação em nuvem e SaaS. Disponível 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.

A

verdade

sobre

SaaS.

Disponível

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 autenticação forte. Disponível 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. Disponível em: <http://www.infoq.com/articles/SaaS-Lifecycle>. Acesso em: 11 maio. 2012.

KOTHARI, C. J. Atendendo Requisitos de Segurança de Aplicativos de Software como Serviço (SaaS). Disponível 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 ameaças virtuais crescem e os orçamentos caem. . [S.l: s.n.]. , 2010.

MELO, C. A.; ARCOVERDE, D. F.; MORAES, É. R. A.; PIMENTEL, J. H. C.; FREITAS, R. Q. Software como Serviço : Um Modelo de Negócio Emergente. . Recife-PE: Centro de informática - Universidade Federal de Pernambuco. , 2007

MOTA, V. P. Desenvolvimento da modelagem de uma ferramenta para gerenciar aplicações SaaS. . [S.l: s.n.]. , 2009 PEDRO, V.; PINHO, F. D. SaaS : Análise de impacto na transformação da investigação e desenvolvimento de produto para serviço. 2009.

RAMOS, F. Gestão de Risco e Compliance: O que vem antes? Disponível 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 segurança em nuvem para fornecedores de aplicativos. Disponível 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. Computação 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

e

arquitetura.

Disponível

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 múltiplos inquilinos. Disponível em: <http://msdn.microsoft.com/ptbr/library/aa479086.aspx>. Acesso em: 15 jul. 2012.