“Divulgue-a, a maior intenção nisso é que o reino de Deus se estabeleça e que nós como servos de Jesus entendamos o nosso papel aqui na terra, e possamos viver e espalhar o reino de Deus por onde passarmos. Deus te abençoe!” – Marcelo Bomfim

Grande Marcelo, bela música, parabéns e DEUS abençoe!

Esperamos que nosso DEUS se agrade com o louvor. Portanto, louvai ao SENHOR …

… com harpa, cantai a ele com o saltério … (Salmos 33:2)
… fazei conhecidas as suas obras … (Salmos 105:1)
… porque ele é bom, porque a sua misericórdia dura para sempre … (Salmos 106:1)
… de todo o meu coração … (Salmos 111:1)
… ao seu nome, porque é agradável … (Salmos 135:3)
… um cântico novo … (Salmos 149:1)
… tudo quanto tem fôlego louve … (Salmos 150:1)

:)

Salmos na Bíblia
Comunidade Alcance
Orvalho

Introdução ao UCON

No artigo publicado por Sandhu e Park [1], em 2003, observou-se que o modelo de matriz de acesso estava inalterável a pelo menos três décadas e que a maioria dos modelos tradicionais tratavam somente de autorização de acesso. Também foi observado que os modelos tradicionais apresentam diversas limitações, tais como no controle de acesso que não pode ser feito de maneira distribuída e a ausência de uma avaliação dinâmica de direitos. Por estes e demais motivos, os autores propuseram um modelo para controle de acesso chamado UCON (Usage Control).
O Modelo UCON é um modelo lógico e matemático que não se preocupa com implementação. Engloba controles tradicionais como DAC (Discretionary Access Control), MAC (Mandatory Access Control) e RBAC (Role-Based Access Control). E suporta controles modernos como TM (Trust Management) e DRM (Digital Rights Management).

Componentes do UCON

Os componentes do modelo UCON são oito: sujeito, atributos do sujeito, objetos, atributos do objeto, direitos, autorizações, obrigações e condições. Abaixo, uma breve descrição de cada componente juntamente com uma letra ou sigla de sua representação [1,2]:
Sujeitos, objetos e direitos são comuns em diversos modelos tradicionais:

• Sujeito (S) – entidade que pode ser uma pessoa/grupo ou sistema que quer ter direitos no acesso a(os) objeto(s).
• Atributos do sujeito (ATT(S)) – alguns exemplos de atributos de sujeito são nome, login, grupo, entre outros (obs.: o modelo UCON não obriga o uso atributos de identificação, para permitir o acesso de sujeitos anônimos).
• Objeto (O) – alguns exemplos são arquivos, vídeos, músicas, programas, etc; ou seja, são entidades as quais um sujeito possui determinados direitos de acesso.
• Atributos do objeto (ATT(O)) – por exemplo, rótulo de segurança, autor, dono, classificação, etc.

Um diferencial do UCON é que os atributos, tanto de sujeitos como de objetos podem ser mutáveis. Essa mutabilidade ocorre por conseqüência do acesso. No caso de atributos imutáveis, estes só poderão ser alterados por ação administrativa.

• Direitos (R) – são privilégios que um sujeito têm sobre o objeto.

Os três fatores de decisão conhecidos como ABC, são:

• Autorização (A) – é um fator que decide se o sujeito pode exercer ou não o seu direito sobre um objeto. As autorizações são baseadas nos atributos do sujeito e nos atributos do objeto.
• Obrigações (B) – são requisitos que o sujeito deve executar antes ou durante o acesso ao objeto. As obrigações não usam os atributos como tomada de decisão, mas para saber qual obrigação aplicar.
• Condições (C) – são fatores relacionados ao ambiente do sistema. Por definição do modelo, as condições podem influenciar os acessos, mas não podem alterar os atributos do sujeito e do objeto.

Família UCON

Processos que ocorrem antes (pre) e durante (ongoing) o acesso, combinados com os fatores de decisão A, B e C e relacionados com mutabilidade e imutabilidade de atributos, formam 24 modelos de UCON:

• Pré: decide-se antes do acesso. Ex: preA (pré-autorização), preB (pré-obrigação) e preC (pré-condição).
• Durante: decide-se durante o acesso. Ex: onA (autorização em curso), onB (obrigação em curso) e onC (condição em curso).

E, no caso de permitir aos atributos serem mutáveis ou não, enumera-se:

• Imutável (0): os atributos dos sujeitos e dos objetos não podem ser alterados.
• Mutável (1, 2 e 3): opcionalmente, os atributos dos sujeitos e dos objetos poderão ser alterados antes (1), durante (2) e depois (3) do acesso.

Não há necessidade de alterar atributos durante o acesso se este está pendente na pré-autorização ou na pré-obrigação: logo, os modelos preA2 e preB2 não existem. E, também, os modelos preC1, onC1, preC2, onC2, preC3 e onC3 não existem por definição própria do modelo UCON. Restando, então, 16 modelos que são detalhados a seguir.

Estados de Transição

O mesmo artigo que propõe uma especificação lógica do UCON [3] apresenta um diagrama de transição de estados. Um diagrama que será utilizado no artigo presente para representar os modelos de UCON. Componentes deste diagrama:

1. Estados: inicial (initial state), solicitando (requesting), acessando (accessing), negado (denied), revogado (revoked), fim (end).
2. Ações: tentar acesso (try access), negar acesso (denyaccess), permitir acesso (permitaccess), revogar acesso (revokeaccess) e encerrar acesso (endaccess). E, também, as ações que permitem a alteração de atributos são: pré-alteração (preupdate), alteração em curso (onupdate) e pós-alteração (postupdate).

Ilustrando o UCON

Apresentam-se, agora, os exemplos dos 16 modelos de UCON. Para fazer esta representação, será utilizado o seguinte cenário:

“Um exército deve atacar seu inimigo. Para isso, o comandante geral deixa  três instruções de ataques armazenadas em um sistema computacional: planoA.doc, planoB.pdf e planoC.avi. O exército está dividido em cinco esquadras: amarela, azul, branca, verde, vermelha. O modelo escolhido para o controlar os acesso no sistema foi o UCONABC.”

Com base neste cenário, exemplos são aplicados a seguir.

Pré-autorização (preA): é realizada antes do direto solicitado ser executado.

• PreA0 – é a abordagem clássica de controle de acesso, os atributos do sujeito e do objeto são verificados para permitir ou não o acesso. Os atributos são imutáveis.

Exemplo: Somente as esquadras amarela, azul, verde e vermelha têm permissão para acessar o arquivo planoA.doc. Logo, a esquadra branca não têm permissão para acessar este arquivo.

• preA1 – além de verificar os atributos do sujeito e do objeto para permitir (ou não) o acesso, também permite opcionalmente alterar estes atributos (mutabilidade).
• preA3 – opcionalmente permite alterar os atributos do sujeito e do objeto após realizar o acesso.

Exemplo: O arquivo planoA.doc poderá ser acessado no máximo 20 vezes. Ou seja, a cada acesso (preA1) o atributo contador do objeto é verificado, e se for menor ou igual a 20, o acesso é permitido; e cada vez que o acesso é realizado (preA3), o atributo contador é incrementado.

Autorização em curso (onA): a autorização é feita em curso, ou seja, a verificação é feita continuamente ou periodicamente. Nestes modelos, o acesso é autorizado sem qualquer pré-decisão e, se determinadas exigências se tornam insatisfeitas, o direito de uso é revogado.

• onA0 – a autorização é feita em curso, mas os atributos do sujeito e do objeto são imutáveis.

Exemplo: De minuto em minuto, é verificado se as esquadras que acessam o arquivo planoB.pdf são das esquadras amarela, azul, verde ou vermelha. Caso contrário, o acesso será barrado (stopped).

• onA1 – a autorização é feita em curso, e os atributos de sujeito e do objeto opcionalmente podem ser alterados antes do acesso.
• onA2 – a autorização é feita em curso, e os atributos de sujeito e do objeto opcionalmente podem ser alterados durante o acesso.
• onA3 – a autorização é feita em curso, e os atributos de sujeito e do objeto opcionalmente podem ser alterados depois do acesso.

Exemplo: O comadante determinou que o arquivo planoB.pdf só pode ser acessado por duas esquadras ao mesmo tempo. Quando ocorrer de uma terceira esquadra abrir o arquivo, o acesso mais antigo será derrubado. Portanto, a cada esquadra que acessar o planoB.pdf (onA1), serão incrementados o contador de acessos do objeto e o contador de tempo do sujeito. Se esta for a terceira esquadra, o sistema vai barrar o acesso da esquadra que têm o contador de tempo maior e decrementar o contador de acessos (onA2). Ao encerrar o acesso (onA3), o contador de acesso é decrementado, e o contador de tempo é zerado.

Pré-obrigação (preB): antes do acesso, verifica funções históricas para identificar atividades que foram cumpridas ou não. E, acaba resultando em verdadeiro ou falso.

• preB0 – a obrigação deve ser cumprida antes de ocorrer o acesso, os atributos de sujeito e de objeto são imutáveis e não interferem no processo de decisão.

Exemplo: Quando se tenta o acesso ao arquivo planoA.doc, abre-se uma tela fazendo uma pergunta conhecida por soldados. Se a resposta escolhida pelo soldado da esquadra estiver correta, o acesso será permitido.

• preB1 – a obrigação deve ser cumprida antes de ocorrer o acesso e, opcionalmente, os atributos do sujeito e do objeto podem ser alterados antes deste acesso.
• preB3 – a obrigação deve ser cumprida antes de ocorrer o acesso e, opcionalmente, os atributos do sujeito e do objeto podem ser alterados depois deste acesso.

Exemplo: O comandante determinou ao sistema que se houver mais de três respostas erradas em uma obrigação, o acesso da esquadra será bloqueado. Portanto, antes de acessar o arquivo planoA.doc, é feita uma pergunta, e a cada erro, o atributo contador de erro é incrementado (preB1). Se ocorreu quatro erros, o acesso é negado (preA1). Agora se houver apenas três erros ou menos, ao encerrar o acesso, o contador de erros é zerado (preB3).

Obrigação em curso (onB): a obrigação deve ser cumprida em curso, continuamente ou periodicamente. Neste modelo, não existe pré-obrigação, pois todas obrigações são tratadas durante o acesso.

• onB0 – a obrigação deve ser cumprida em curso, os atributos de sujeito e de objeto são imutáveis e não interferem no processo de decisão.

Exemplo: O comandante determinou que enquanto uma esquadra acessa o arquivo planoB.pdf, deve também estar acessando arquivo planoA.doc. Esta verificação será feita continuamente, e caso o arquivo planoA.doc seja fechado, o acesso ao planoB.pdf será revogado.

• onB1 – a obrigação deve ser cumprida em curso e, opcionalmente, os atributos de sujeito e de objeto poderão ser alterados antes do acesso.
• onB2 – a obrigação deve ser cumprida em curso e, opcionalmente, os atributos do sujeito e do objeto poderão ser alterados durante o acesso.
• onB3 – a obrigação deve ser cumprida em curso e, opcionalmente , os atributos do sujeito e do objeto poderão ser alterados depois do acesso.

Exemplo: O comandante determinou que é obrigatório ao sujeito manter o cursor do mouse sobre a janela no momento da leitura do planoB.pdf. E, por questões forenses, o velocímetro do mouse deverá ser armazenado em logs. Portanto, o sujeito têm acesso direto ao planoB.pdf e o atributo velocímetro do mouse é zerado (onB1). Durante o acesso o velocímetro é contabilizado (onB2), e caso o mouse saia da janela atual, o acesso ao planoB.pdf será revogado. Ao final, quando o acesso é encerrado (onB3), o valor resultante do velocímetro do mouse é armazenado em arquivo de log.

Pré-condição (preC): é uma pré-condição do ambiente para ser atendida antes de realizar o acesso.

• preC0 – uma pré-condição onde os atributos de sujeito e objeto são imutáveis.

Exemplo: Antes de permitir o acesso aos documentos “avi”, verificar se a carga do sistema está abaixo de 3%.

Condição em curso (onC): é uma condição do ambiente que deve ser atendida  durante os acessos.

• onC0 – uma condição que deve ser atendida continuamente ou periodicamente, onde os atributos de sujeito e objeto são imutáveis.

Exemplo: O consumo de memória e CPU não devem ultrapassar de 80%. Se isso ocorrer, os acessos serão revogados até que o sistema normalize.

Considerações Finais

Apresentou-se aqui de maneira simples o funcionamento do modelo UCONabc. Quando se trata de modelos de controle de acesso, este modelo é considerado expressivo e flexível. Por se tratar de um modelo um tanto completo e complexo, até então não foram encontradas implementações, e as que existem são incompletas e não implementam recursos de tempo real ou de atualização de atributos.
Procurou-se aqui apenas demonstrar o funcionamento básico deste modelo. Mais detalhes de como funciona o monitor de referência e a comparação entre os modelos existentes, poderão ser encontrados nos artigos que estão nas referências.

Referências:

[1] R. Sandhu and J. Park, Usage Control: A Vision for Next Generation Access Control, The Second International Workshop on Mathematical Methods, Models and Architectures for Computer Networks Security, 2003.
[2] Jaehong Park , Ravi Sandhu, The UCONABC usage control model, ACM Transactions on Information and System Security (TISSEC), v.7 n.1, p.128-174, February 2004.
[3] Xinwen Zhang , Jaehong Park , Francesco Parisi-Presicce , Ravi Sandhu, A logical specification for usage control, Proceedings of the ninth ACM symposium on Access control models and technologies, June 02-04, 2004, Yorktown Heights, New York, USA.

Agora falando sério. Não lembro quando, mas quando nasci fui batizado! De certo que olharam pra mim e disseram: “Se arrependa moleque de todo mal que você fez”! Poxa, devia ter feito muito mal né, com alguns dias de vida dá pra fazer muita zona!

Claramente a Bíblia se refere ao batismo como arrependimento dos pecados, ou seja, a pessoa deve estar consciente dos seus erros. Até o SENHOR JESUS que não precisava, mas recebeu o batismo quando devia ter uns 30 anos de idade. A foto acima é do nosso batismo em Mandirituba – PR.

Para os que não querem nada com nada, saibam que no mundo só existem 2 tipos de pessoas:

1) Pessoas más!

2) Pessoas más que se arrependem!

Algumas referências sobre batismo e arrependimento na Bíblia: Lucas 3:3 e Mateus 3:11.

Partindo da comparação de que um computador sem segurança é semelhante a uma sociedade sem lei. Landwehr defende que assim como as leis regem a proteção e o bem da sociedade, as políticas de segurança são necessárias para a proteção da informação em sistemas computacionais. As políticas são um conjunto de regras que visam atender um objetivo específico como, por exemplo, evitar que informações confidenciais sejam roubadas ou divulgadas indevidamente de maneira que possam causar prejuízos ou danos maiores.

A política de segurança deve se preocupar com a proteção da informação, e para distinguir intrusos de usuários legítimos é necessário estabelecer um perímetro de segurança; pois o intruso é identificado por “cruzar a linha” sem autorização. Mesmo que legítimo, um usuário pode ser mal intencionado (ameaça) e tentar infligir danos ao explorar uma fraqueza do sistema (vulnerabilidade). Se a política de segurança não é imposta pelo sistema, resulta em uma decisão do administrador em evitar ou aceitar este tipo de risco. Logo, aceitar o risco significa estar ciente das ameaças e das vulnerabilidades.

Das propriedades de segurança, a informação deve ter confidencialidade (não permitir divulgar sem autorização), integridade (não permitir modificar sem autorização) e disponibilidade (divulgar para usuários legítimos quando requerido). Para essas três anteriores a autenticação (que identifica o sujeito) é um pré-requisito. O artigo também trata de diversos princípios de segurança. Dentre alguns, a responsabilidade é um meio em que se pode processar judicialmente o autor da ação indevida. Ou seja, através de mecanismos de segurança, pode-se identificar o autor. São estes mecanismos que delimitam o domínio e os privilégios, que autenticam e autorizam o usuário e que também identificam as suas ações através de auditoria. Dentre os diversos assuntos que o autor esclarece em seu artigo, fica claro que cada vez mais a insegurança se torna aparente, seja por vulnerabilidades conhecidas ou, até mesmo, uma administração inadequada do sistema.

Este artigo oferece uma boa leitura para quem deseja dar um passo inicial no campo de segurança da informação e da computação. Ainda que a publicação tenha data do início da década, os assuntos e problemas que são discutidos neste artigo são relevantes até o dia de hoje.

Carl E. Landwehr, têm mais de 25 anos de experiência em pesquisa na área e atualmente é editor associado ao IEEE Transactions e diretor/fundador do programa de pesquisa chamado National Science Foundation Cyber Trust.

http://www.springerlink.com/content/nwk24a62ur0dfu9j/

Parece minha área de trabalho, mas não é!

É a soma das fotos:

Divirta-se: pt.picjoke.com

Agora é minha área de trabalho! :D