5.1 O Catálogo de Segurança
5.1.2 Segundo Nível de Abstração
5.1. O Catálogo de Segurança 65
– recuperação de desastres:políticas e procedimentos aplicados na recupera-ção de “desastres“ induzidos no software por usuário ou softwares de terceiros (BENITTI; RHODEN, 2015);
– duplicar servidor para armazenamento de dados:promove menor chance de tempo onde ocorra a inatividade dos dados. Com a utilização de dois ou mais servidores em funcionamento, a disponibilidade dos dados do software é maior (DATE, 2004)(AFFLECK; KRISHNA, 2012);
– realizar espelhamento do banco de dados:compreende-se como duas có-pias de um único banco de dados que geralmente reside em máquinas diferentes (DATE, 2004)(AFFLECK; KRISHNA,2012);
∙ auditoria e controle:especificação dos aspectos que devem ser contemplados para proporcionar a auditoria e o controle (BENITTI; RHODEN, 2015);
∙ contestabilidade e responsabilização: capacidade do software em quantificar as ações e os eventos, com intuito de comprovar sua ocorrência (BENITTI; RHODEN, 2015);
– cronologia(logs): registro de alterações no software (BENITTI; RHODEN, 2015);
∙ autenticidade: capacidade do software em identificar que um objeto ou recurso é o que ele realmente declara ser (BENITTI; RHODEN,2015), e
∙ confiabilidade: capacidade do software em realizar e manter seu funcionamento quando submetido em circunstâncias de rotina (BENITTI; RHODEN, 2015).
66 Capítulo 5. Catálogo de Segurança
Tabela 10 – Mapeamento das metas flexíveis com as camadas do MVC - Parte 1.
id Meta flexível Nível de
satisfação Descrição Referência Camada
1 “precisão
[software]”
Suficientemente
Satisfeita Garante que um ou mais objetos este-jam ligados a uma única entidade do domínio. Além disso, impacta direta-mente a Model pois é a camada que representa os aspectos do domínio da aplicação.
- Atributo de precisão: precisão de um para um.
(CHUNG et al.,2012)
(BUSCHMANN et al.,1996) model
2 “precisão
[software]”
Suficientemente
Satisfeita Garante que os objetos sejam instanci-ados da maneira correta dentro da mo-del.
- Atributo de precisão: Propriedade da precisão.
(CHUNG et al.,2012)
(BUSCHMANN et al.,1996) Model
3 “autenticidade [informação]”
Satisfeita
Suficientemente A utilização de triggers em banco de dados promove a autenticidade e a ve-rificação da integridade do dado. Além disso, pode ser utilizada para realiza-ção de auditoria em tabelas.
4 “integridade [software]”
Satisfeita Suficientemente 5
“auditoria e controle [informação]”
Satisfeita Suficientemente
(DATE,2004) Banco
de Dados
6
“controle de acesso usuário
[software]”
Parcialmente
Satisfeita O método de autenticação dos dados retorna a instância do usuário, quando a senha está correta. Esse aspecto é implementado diretamente na Control-ler. Entretanto, possui clara relação com a View e com a base de da-dos. Considera-se “Parcialmente Sa-tisfeita”, pois há dependência com a operacionalização “Autorizar Acesso a Contas", a qual contribui para a satis-fação dessa meta flexível “controle de acesso [software]”.
(FUENTES,2014) Controller
7 “confiabilidade [informação]”
Suficientemente
Satisfeita Garante que o conjunto de dados a se-rem armazenados na base de dados es-tejam relativamente fidedignos. Usa-se
“relativamente”, pois não há como ga-rantir algo pleno, se tratando de crité-rios tão abstratos. Nesse caso, “relati-vamente” sugere que seja o mais fide-digno/confiável possível”.
(FUENTES,2014) View
8
“controle de acesso dos componentes
MVC [nível arquitetural]”
Parcialmente
Satisfeita Garante que os componentes daView, os quais dependem de outros compo-nentes que se encontram em outras camadas do modelo MVC, reconhe-çam a necessidade de atualizar as te-las, adequando-as às demandas enca-minhadas via Controller (por exem-plo) e em compatibilidade com os da-dos especificada-dos naModel. Considera-se “parcialmente satisfeita”, pois há dependência com a implementação do padrão de projeto estrutural Compo-site. A implementação é sugerida como operacionalização que contribue para satisfação dessa meta flexível, “con-trole de acesso dos componentes MVC [nível arquitetural].”
(BAPTISTELLA,2011)
(BUSCHMANN et al.,1996) View
5.1. O Catálogo de Segurança 67
Tabela 11 – Mapeamento das metas flexíveis com as camadas do MVC - Parte 2.
id Meta flexível Nível de
satisfação Descrição Referência Camada
8
“controle de acesso dos componentes
MVC [nível arquitetural]”
Parcialmente
Satisfeita Garante que os componentes daView, os quais dependem de outros compo-nentes que se encontram em outras camadas do modelo MVC, reconhe-çam a necessidade de atualizar as te-las, adequando-as às demandas enca-minhadas via Controller (por exem-plo) e em compatibilidade com os da-dos especificada-dos naModel. Considera-se “Parcialmente Satisfeita”, pois há dependência com a implementação do padrão de projeto estrutural Compo-site. A implementação é sugerida como operacionalização que contribue para satisfação dessa meta flexível, “con-trole de acesso dos componentes MVC [nível arquitetural].”
(BAPTISTELLA,2011)
(BUSCHMANN et al.,1996) View
9
“controle de acesso dos componentes
MVC [nível arquitetural]”
Parcialmente
Satisfeita Garante que aModelesteja menos aco-plada em relação à View e à Con-troller, viabilizando essa relação atra-vés de boas práticas da Engenharia de Software. Uma dessas práticas é su-gerida como operacionalização na Fi-gura 12, apoiando-se no uso de Pa-drões de Projeto. Considera-se parci-almente satisfeita, pois há dependên-cia com a implementação do padrão de projeto comportamentalObserver, por exemplo. Essa implementação é suge-rida como uma operacionalização pos-sível em atendimento a essa demanda e contribui para a satisfação dessa meta flexível, “controle de acesso dos com-ponentes MVC[nível arquitetural]”.
(BAPTISTELLA,2011)
(BUSCHMANN et al.,1996) Model
10
“controle de acesso dos componentes
MVC [nível arquitetural]”
Parcialmente
Satisfeita Garante menor acoplamento entre as camadas MVC. Sugere-se que tal as-pecto seja apoiado no uso de Padrões de Projeto. Portanto, acredita-se que o padrão de projeto Strategy, imple-mentado na Controller, permita me-nor acoplamento entre View e Mo-del, sendo, de fato, responsabilidade daController intermediar essa relação utilizando decisões estratégicas. Vale ressaltar que, com o uso desse padrão de projeto decisões podem ser toma-das em tempo de execução, alterando o comportamento do software em fun-ção das demandas conhecidas dinami-camente. Dessa forma, a tendência é de maior cumprimento de boas prá-ticas já acordadas no padrão arquite-tural MVC. Considera-se parcialmente satisfeita, pois há dependência com a implementação do padrão de projeto comportamental Strategy, por exem-plo. Essa implementação é sugerida como uma operacionalização possível em atendimento a essa demanda, e contribui para a satisfação dessa meta flexível, “controle de acesso dos com-ponentes MVC[nível arquitetural]”.
(BAPTISTELLA,2011)
(BUSCHMANN et al.,1996) Controller
68 Capítulo 5. Catálogo de Segurança
Resumo do Capítulo
Neste capítulo, foi apresentada uma primeira versão do Catálogo de Segurança proposto nessa pesquisa. Adicionalmente, foram apontados os principais impactos e as contribuições das informações do Catálogo de Segurança em relação às camadas do Padrão Arquitetural MVC. Ressalta-se que, o Catálogo foi especificado apoiando-se na literatura, conforme pode ser observado considerando a rastreabilidade, apresentada na seção5.1.1 evidenciando o primeiro nível de abstração. Nesse nível, foram descritas as metas flexíveis associadas à Segurança. O Catálogo de Segurança especificou as correlações e os impactos entre as metas flexíveis, bem como as operacionalizações.. O segundo nível de abstração foi apresentado na seção5.1.2, demonstrando o mapeamento entre as metas flexíveis e as camadas do Padrão Arquitetural MVC.
Por fim, cabe mencionar que o Catálogo de Segurança ainda possui mais um ní-vel de abstração, o qual será demonstrado no Capítulo 6, pois só foi possível mapear a correlação entre as operacionalizações e as camadas MVC com a aplicação em cenários.
Tal prática permitiu apresentar como os critérios de qualidade podem ser suficientemente tratados e satisfeitos a nível de código.
69
6 Resultados Obtidos
Neste capítulo, são apresentadas as primeiras aplicações do Catálogo de Segurança e o mapeamento no terceiro nível de abstração (entre operacionalizações e as camadas do Padrão Arquitetural MVC). Para isso, foi utilizado o conceito de personas, apresentado na seção 2.7, com o objetivo de demonstrar os cenários nos quais o catálogo pode ser aplicado. Portanto, realizou-se a simulação de cinco cenários para validar a aplicação do Catálogo de Segurança.
O capítulo é dividido, inicialmente, pelos cenários contextualizados dentro de cada persona. Os cenários têm a descrição dapersona, identificação da possível solução (quando necessário descrever para o cenário), e a aplicação do catálogo. Ao final do capítulo, são apresentadas as primeiras impressões sobre a aplicação do catálogo.