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) 4

FIGURA 2- PARTILHA DE CUSTOS DE AMBIENTE TRADICIONAL DE TI. FONTE: CHONG ET AL (2006) 5

FIGURA 3 - DIVISÃO TÍPICA DE INVESTIMENTO EM AMBIENTES SAAS. FONTE: CHONG ET AL (2006) 7

FIGURA 4 - SAAS VANTAGEM DE CUSTO SOBRE SERVIDOR BASEADO EM SISTEMAS TRADICIONAIS.

FONTE: BRIVO, 2009 10

FIGURA 5 - ANALISE DE CUSTO INSTALAÇÃO DE SISTEMAS BASEADO EM SERVIDOR E SAAS. FONTE:

BRIVO, 2006 11

FIGURA 6 - CONCEITO DE CALDA LONGA. FONTE: ANDERSON (2006). 13

FIGURA 7 - ABORDAGEM USANDO UM BANCO DE DADOS DISTINTO PARA CADA INQUILINO. FONTE:

WOLTER ET AL. (2006). 22

FIGURA 8 - ABORDAGEM EM QUE CADA INQUILINO POSSUI SEU PRÓPRIO CONJUNTO DE TABELAS

NUMA MESMA BASE DE DADOS. FONTE: WOLTER ET AL.(2006). 23

FIGURA 9 - CICLO DE VIDA DO DESENVOLVIMENTO SAAS. FONTE: KOMMALAPATI (2011). 24

FIGURA 10 - USUÁRIO E PERMISSÕES CONTIDAS EM BANCO DE DADOS INDEPENDENTE. FONTE:

SOFTWARE (2008). 36

FIGURA 11 - MODELO DE GERÊNCIA DE USUÁRIO 37

FIGURA 12 - DIAGRAMA GERENCIAMENTO DE INSERÇÃO DE CADASTRO 40

FIGURA 13 - DIAGRAMA DE SEQUÊNCIA DE GERENCIAMENTO DE PERMISSÕES. 41

FIGURA 14 - DIAGRAMA DE SEQUÊNCIA DE AUTENTICAÇÃO DO USUÁRIO FINAL. 44

FIGURA 15 - USO DO SSO. FONTE: (SOFTWARE, 2008). 46

FIGURA 16 - DIAGRAMA DE CASO DE USO LOG. 48

FIGURA 17 - GERENCIAMENTO DE LOG. FONTE: MOTA, 2009. 49

ix

LISTA DE TABELAS

TABELA 1- GERÊNCIA DE USUÁRIO. 39

TABELA 2- AUTENTICAR USUÁRIO. 43

x

LISTA DE SIGLAS

Sigla Significado

SaaS

TI

SOA

LAN

VPN

BPO

TCO

SLA

SOAP

XML

POP

IMAP

HTTP

SSO

SAML

STS

LDAP

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 INTRODUÇÃO ...................................................................................................................... 1

2 DEFINIÇÃO – SOFTWARE AS A SERVICE SAAS ............................................................ 4

2.1 CONCEITOS DE SOFTWARE COMO SERVIÇO ......................................................... 7

2.2 ANÁLISE DE CUSTO .................................................................................................... 9

2.3 CONCEITO CAUDA LONGA APLICADA SAAS ......................................................... 11

2.4 SLA - SERVICE LEVEL AGREEMENTS ..................................................................... 13

2.5 VANTAGENS E DESVANTAGENS ............................................................................. 15

2.6 SAAS VERTICAL E HORIZONTAL ............................................................................. 16

2.7 SAAS CORPORATIVO ............................................................................................... 17

3 ARQUITETURA SAAS ....................................................................................................... 18

3.1 CICLO DE DESENVOLVIMENTO ............................................................................... 19

3.2 SEGURANÇA SAAS ................................................................................................... 26

3.3 GESTÃO DE RISCOS SAAS ....................................................................................... 28

3.4 VULNERABILIDADES SAAS ...................................................................................... 28

3.5 MAU COMPORTAMENTO DO SERVIÇO .................................................................. 29

3.6 COMPUTAÇÃO CONFIÁVEL ..................................................................................... 29

3.7 VIOLAÇÃO DOS DADOS DOS CLIENTES ................................................................. 30

3.8 COMPARTILHAMENTO DE RECURSOS .................................................................. 31

3.9 AMEAÇAS A REDE ..................................................................................................... 31

3.10 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 CONCLUSÃO ..................................................................................................................... 51

6 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, torna-

se 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 cliente-

fornecedor, 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 mal-

intencionado 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 multi-

tenant.

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 diferentes dos ambientes comuns. O

gerenciamento da plataforma SaaS deve começar no momento do

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 usuários devem estar

devidamente cadastrados, para

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 o usuário for

autenticado seus dados 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/pt-

br/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:

<http://info.abril.com.br/corporate/noticias/072008/28072008-1.shtml>. Acesso

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-11-

27.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=pt-

PT&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-a-

service/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/pt-

br/library/aa479086.aspx>. Acesso em: 15 jul. 2012.