Foi feita uma an´alise te´orica sobre o n´umero de acessos feitos ao espac¸o de tuplos em cada actualizac¸˜ao. Atrav´es da verificac¸˜ao de cada algoritmo, definiu-se o n´umero de acessos de cada componente do sistema, nomeadamente o manager e o enforcer, ao espac¸o de tuplos. Fazemos a distinc¸˜ao entre dois tipos de acesso: escrita (W ) e leitura (R). As operac¸˜oes de escrita s˜ao mais custosas, precisando de cinco passos de comunicac¸˜ao, para garantir a ordem total nas interacc¸˜oes enquanto que a leitura apenas precisa de dois2 [3].
A Tabela 3.2 apresenta o n´umero de acessos realizados em um ou mais dom´ınios, por parte do manager e do enforcer.
1 dom´ınio k dom´ınios Manager (n + 1)W + nR k((n + 2)W + nR) Enforcer W + (n + 2)R W + 3R
Tabela 3.2: N´umero de acessos realizados ao espac¸o de tuplos. A vari´avel n identifica o n´umero de enforcers.
O manager na actualizac¸˜ao de pol´ıticas em um dom´ınio faz (n+1) escritas (Algoritmo 1, linhas 3 e 5) mais n leituras (Algoritmo 1, linha 9). O enforcer escreve apenas uma vez no espac¸o (Algoritmo 2, linha 8) e faz (n + 2) leituras (Algoritmo 2, linhas 2, 6 e 12).
Cap´ıtulo 3. Algoritmos de actualizac¸˜ao de pol´ıticas coordenadas 35
Na actualizac¸˜ao de pol´ıticas em v´arios dom´ınios, o manager faz k(n + 2) escritas (Algoritmo 3, linhas 4, 6 e 26) e nk leituras (Algoritmo 3, linha 13), i.e., as escritas e as leituras s˜ao efectuadas em todos os k dom´ınios. O enforcer, ao contr´ario do manager, faz apenas 1 escrita no espac¸o de tuplos (Algoritmo 4, linha 8) e 3 leituras (Algoritmo 4, linhas 2, 6, 10).
A diferenc¸a entre a actualizac¸˜ao de pol´ıticas em um dom´ınio e v´arios ´e que a primeira tem um menor n´umero de acessos por parte do manager (porque s´o existe um dom´ınio). O enforcer na actualizac¸˜ao de pol´ıticas em v´arios dom´ınios tem menos acessos ao espac¸o de tuplos, porque este espera pela resposta do manager para concluir o processo, n˜ao havendo a necessidade de ler tuplos de todos os enforcers do espac¸o, como acontece na actualizac¸˜ao em um dom´ınio.
Uma poss´ıvel optimizac¸˜ao para melhorar o n´umero de acessos, era criar uma operac¸˜ao outAll que inserisse atomicamente v´arios tuplos no espac¸o atrav´es de uma ´unica operac¸˜ao.
3.11
Considerac¸˜oes Finais
Neste cap´ıtulo descreveu-se o SACP (Sistema de Actualizac¸˜ao Coordenada de Pol´ıticas) e a importˆancia de cada interveniente no seu funcionamento, nomeadamente o manager, o enforcer e o servic¸o de coordenac¸˜ao. Depois da arquitectura definida, descreveu-se os algoritmos de actualizac¸˜ao coordenada de pol´ıticas juntamente com as pol´ıticas do servic¸o de coordenac¸˜ao, o DEPSPACE. O processo de actualizac¸˜ao de pol´ıticas coordenadas pode
ocorrer em um ou mais dom´ınios.
Agora que se tem toda a percepc¸˜ao do funcionamento do sistema, o cap´ıtulo seguinte descreve a implementac¸˜ao de um prot´otipo que foi desenvolvido tendo em conta os algo- ritmos descritos nas secc¸˜oes anteriores.
Cap´ıtulo 4
Concretizac¸˜ao
Agora que se tem os algoritmos de coordenac¸˜ao definidos, que descrevem o funciona- mento do SACP, criou-se um prot´otipo (um proof-of-concept) que aplica toda a teoria dos cap´ıtulos anteriores. A criac¸˜ao do prot´otipo visa provar o funcionamento do SACP.
Este cap´ıtulo descreve as ferramentas utilizadas e todo o desenho do prot´otipo.
4.1
Ferramentas Utilizadas
A escolha das ferramentas utilizadas no desenvolvimento de software s˜ao muito impor- tantes no desenvolvimento do projecto. Estas podem determinar a criac¸˜ao de um produto com maior ou menor qualidade.
As ferramentas utilizadas podem ser dividas nas seguintes categorias: desenho, pro- gramac¸˜ao documentac¸˜ao e experimentac¸˜ao.
A seguir s˜ao descritas, as ferramentas utilizadas neste projecto. Desenho
As figuras e diagramas UML foram desenhadas num programa de desenho denominado OmniGraffle1.
Programac¸˜ao
As ferramentas de programac¸˜ao permitem auxiliar o processo de codificac¸˜ao de software. Na realizac¸˜ao deste projecto foi usado um ambiente de desenvolvimento integrado, que possibilita a edic¸˜ao de c´odigo fonte, compilac¸˜ao, execuc¸˜ao e teste. Foram estudadas v´arias soluc¸˜oes, sendo no final escolhido o IDE NetBeans2 j´a que todo o software seria desen- volvido em Java e que este possu´ıa um criador de interfaces gr´aficas avanc¸ado. Os testes foram efectuados com o aux´ılio do debugger inclu´ıdo no IDE escolhido devido `as suas interfaces gr´aficas e `a sua integrac¸˜ao.
1http://www.omnigroup.com/applications/OmniGraffle/ 2http://www.netbeans.org
Cap´ıtulo 4. Concretizac¸˜ao 38
Na criac¸˜ao deste prot´otipo foi usado o servic¸o de coordenac¸˜ao DEPSPACE3, cujo ob-
jectivo era o de fornecer uma comunicac¸˜ao segura entre todos os intervenientes do SACP (entre o manager e o enforcer).
Documentac¸˜ao
Foi utilizada a ferramenta de gest˜ao de projectos gantt project4 na calendarizac¸˜ao e reali-
zac¸˜ao de diagramas de Gantt. A documentac¸˜ao escrita, ou seja a redacc¸˜ao de relat´orios foi realizada em LaTeX5, usando o editor de texto gedit6 com o m´odulo LaTeXPlugin7.
Foi utilizado o JavaDoc para gerar toda a documentac¸˜ao do c´odigo fonte.
Experimentac¸˜ao
Foram utilizadas v´arias ferramentas dispon´ıveis num ambiente Linux, i.e., o Gnome Ter- minal8. Foi tamb´em usada a linguagem de programac¸˜ao shell para criar v´arios scripts para simular de uma forma autom´atica, a rede da infra-estrutura cr´ıtica.
4.2
Desenho
Como foi descrito no cap´ıtulo anterior, o sistema ´e constitu´ıdo por v´arias entidades, nome- adamente, o manager, o enforcer e o servic¸o de comunicac¸˜ao. De seguida descrevemos como estes intervenientes est˜ao implementados no prot´otipo.
4.2.1
Manager
O manager ´e a entidade principal do SACP, ´e respons´avel por iniciar e coordenar o pro- cesso de distribuic¸˜ao de pol´ıticas de seguranc¸a.
Na Figura 4.1 est´a representado o diagrama de classes UML do manager. Alguns pormenores n˜ao relevantes foram omitidos para uma melhor compreens˜ao do desenho do sistema.
As operac¸˜oes que o manager executa, est˜ao inseridas na interface IManagerControl- lerque cont´em as duas operac¸˜oes: deployPolicy() e deployPolicyAllGroups(). A primeira ´e respons´avel por iniciar o processo de actualizac¸˜ao de pol´ıticas em um determinado dom´ınio (associado a um espac¸o de tuplos), tamb´em descrito no algoritmo da Secc¸˜ao 3.4. Por fim, a segunda operac¸˜ao ´e respons´avel por iniciar o processo de actualizac¸˜ao de
3http://www.navigators.di.fc.ul.pt/software/depspace/ 4http://www.ganttproject.biz 5http://www.latex- project.org/ 6http://projects.gnome.org/gedit/ 7http://sourceforge.net/projects/gedit-latex 8http://directory.fsf.org/project/gnome-terminal/
Cap´ıtulo 4. Concretizac¸˜ao 39 +barrierCreatedEvent(tuple) +changeContextEvent(tuple) +remainingToDeployEvent(tuple[]) +timeout() +newPolicyAnnouncedEvent(tuple) +createPolicyEvent(tuple) IManagerListener Host +getAcessor() SpaceOperations +deployPolicy(TupleData) +deployPolicyAllGroups(TupleData[]) IManagerController ManagerController 1 1 IManager ITupleFactory 1..* 1 1 1 1 1 1 1 1..* 1 Group DepSpace Manager DepSpaceTupleFactory comunicação com o serviço de coordenação ManagerGUI contém contém contém < < < +run() +terminate() Thread 1 1..*
Threads que escutam os vários domínios, com o objectivo de esperar que todos os
enforcers apliquem as suas políticas.
Cap´ıtulo 4. Concretizac¸˜ao 40
pol´ıticas em v´arios dom´ınios, tamb´em descrito no algoritmo da Secc¸˜ao 3.5. A classe Ma- nagerController concretiza o interface IManagerController e executa as operac¸˜oes que est˜ao implementadas em classes de baixo n´ıvel como o manager.
O manager cont´em uma f´abrica de tuplos, respons´avel por criar qualquer tuplo a ser inserido no espac¸o. Este padr˜ao de desenho permite centralizar toda a criac¸˜ao de tuplos numa classe com o objectivo de no futuro, se houver alguma alterac¸˜ao, esta seja f´acil de gerir.
Apenas a classe Manager tem acesso `a classe Thread, onde cria v´arias instˆancias do processo de distribuic¸˜ao de pol´ıticas para v´arios dom´ınios com o objectivo de “ouvir” todos estes, pelas respostas dos enforcers. Na pr´atica, as linhas 8 a 23 do Algoritmo 3 s˜ao executadas em paralelo por essas threads.
A classe Group ´e respons´avel pela comunicac¸˜ao, isto ´e, se o manager decidir inserir uma nova pol´ıtica no espac¸o tem que aceder `a instˆancia do grupo respectiva. Esta instˆancia tem acesso ao espac¸o de tuplos atrav´es da classe SpaceOperations, que como o nome indica, cont´em todas as operac¸˜oes a realizar no espac¸o de tuplos actual.
A interface gr´afica implementa um “event listener” que executa um dos seus m´etodos quando um determinado evento ocorre. Por exemplo, quando o manager insere tuplos POLICY (tuplos que contˆem a pol´ıtica de seguranc¸a de um ou mais enforcers) ´e despo- letado o evento createPolicyEvent(tuple), m´etodo da interface IManagerListener.
4.2.2
Enforcer
Esta entidade ´e respons´avel por aplicar as pol´ıticas enviadas pelo manager.
O enforcer cont´em apenas uma operac¸˜ao, denominada listenTupleSpace(), como est´a representado no diagrama de classes na Figura 4.2, cujo objectivo ´e escutar o espac¸o de tuplos por novas pol´ıticas de seguranc¸a e executar um conjunto de operac¸˜oes quando o processo de actualizac¸˜ao de pol´ıticas ´e iniciado.
A interface IEnforcer cont´em todas as operac¸˜oes que s˜ao executadas, quando o enfor- cer recebe uma nova pol´ıtica, por exemplo, o applyPolicy(policy) (que aplica a pol´ıtica no sistema) e o sendDeployed(tuple) (que envia um tuplo para identificar que o seu dis- positivo recebeu com sucesso a nova pol´ıtica).
No enforcer, como no manager, existe um “event listener” que possui um conjunto de eventos que s˜ao executados durante o processo de actualizac¸˜ao de pol´ıticas. Um exem- plo desses eventos ´e o policyChanged(policies) que ´e despoletado quando existe uma alterac¸˜ao de pol´ıticas no sistema, passando como parˆametro as pol´ıticas em aplicac¸˜ao no enforcer.
Cap´ıtulo 4. Concretizac¸˜ao 41 +policyAnnounceEvent(tuple) +barrierCreatedEvent(tuple) +policyChangedEvent(policies) +consumedPolicyEvent(tuple) +notConsumedPolicyEvent(tuple) +deployedEvent(tuple) IEnforcerListener Host +listenTupleSpace() IEnforcerController EnforcerController ITupleFactory 1..* 1 1 1 1 1 1 1 1 1 Group DepSpace Enforcer DepSpaceTupleFactory comunicação com o serviço de coordenação EnforcerGUI pertence contém < < +applyPolicy(policy) +undoApplyPolicy(policies) +consumeOrNotPolicy(group, tuple) +applyPolicy(policy, utype) +sendDeployed(tuple) +waitForManagerContext(tuple) IEnforcer 1 1 contém < +getAcessor() SpaceOperations
Cap´ıtulo 4. Concretizac¸˜ao 42
4.2.3
Comunicac¸˜ao
A comunicac¸˜ao entre os n´os da rede onde a antepara est´a em funcionamento ´e garantida pelo servic¸o de coordenac¸˜ao tolerante a intrus˜oes, o DEPSPACE (apresentado na Secc¸˜ao 2.4.2). O acesso ao DEPSPACEd´a-se atrav´es de duas classes: DepSpaceAcessor e DepS-
paceManager, que s˜ao encapsulados na classe SpaceOperations, como est´a representado nas Figuras 4.1 e 4.2.
A comunicac¸˜ao entre as r´eplicas do DEPSPACE e todos os n´os que comunicam com as mesmas, ´e feita de forma segura. O DEPSPACEgarante que todos os intervenientes no
processo de distribuic¸˜ao de pol´ıticas, estejam autenticados atrav´es de certificados digitais. Os pormenores de funcionamento do algoritmo foram omitidos, porque estes n˜ao s˜ao o foco desta dissertac¸˜ao.
4.3
Execuc¸˜ao da Ferramenta
Os dois programas desenvolvidos, tanto a parte do manager como a do enforcer tˆem uma interface gr´afica. O enforcer necessita de alguns parˆametros para ser executado ao contr´ario do manager.
Cada manager e cada enforcer possui um ficheiro de configurac¸˜ao que cont´em a topologia da rede da IC que necessita de ser configurado (o nome do ficheiro ´e topo- logy.config), como est´a descrito na Figura 4.3.
Algarve 2 0 1 Setubal 2 2 3 Lisboa 1 4 nome do espaço número de enforcers id dos enforcers
Figura 4.3:Exemplo de configurac¸˜ao da topologia de rede no ficheiro topology.config.
4.3.1
DepSpace
O servic¸o de coordenac¸˜ao necessita de ser executado primeiro, antes do manager e do enforcer, com o seguinte comando: “java br.ufsc.das.Main [replica id]”. O parˆametro
Cap´ıtulo 4. Concretizac¸˜ao 43
replica idrepresenta o identificador da r´eplica, j´a que o servic¸o de coordenac¸˜ao ´e repli- cado.
4.3.2
Manager
Para executar o manager necessitamos apenas de executar o seu interface gr´afico: “java gui.ManagerGUI”. Este ´e executado em segundo, depois do servic¸o de coordenac¸˜ao DEPSPACE. estado da última operação vermelho se estiver em actualização
escolher entre actualizar num domínio (LAN) ou vários domínios (WAN)
parâmetros de actualização
de políticas
Figura 4.4:Interface gr´afico do manager - Actualizac¸˜ao de Pol´ıticas em um dom´ınio.
O interface gr´afico apresentado na Figura 4.4 apresenta as opc¸˜oes dispon´ıveis para a actualizac¸˜ao de pol´ıticas em um dom´ınio, ao contr´ario da Figura 4.5, no qual se po- dem alterar as configurac¸˜oes de cada dom´ınio em particular, para de seguida se iniciar o processo de actualizac¸˜ao de pol´ıticas em v´arios dom´ınios.
4.3.3
Enforcer
Por ´ultimo, para criar um Enforcer precisamos de executar na linha de comandos o se- guinte: “java gui.EnforcerGUI [id] [espac¸o]”
O id ´e o identificador ´unico do n´o no espac¸o l´ogico a que pertence. O parˆametro espac¸otem como func¸˜ao especificar o nome l´ogico do espac¸o de tuplos (pode ser usado para representar redes, regi˜oes, subredes, entre outros) com que este n´o vai comunicar.
Cap´ıtulo 4. Concretizac¸˜ao 44
configuração da política que será enviada para todos os domínios política a ser enviada para todos os grupos
Figura 4.5:Interface gr´afico do manager - Actualizac¸˜ao de Pol´ıticas em v´arios dom´ınios.
políticas actuais a serem aplicadas estado da última operação tipo de actualização aplicado durante a operação log de todas as operações domínio associado identificador do Enforcer
Cap´ıtulo 4. Concretizac¸˜ao 45
A interface gr´afica do enforcer (ver Figura 4.6) serve apenas para visualizac¸˜ao das operac¸˜oes de actualizac¸˜ao, j´a que na pr´atica n˜ao se espera que as anteparas tenham inter- face gr´afica.