Header Web
Logo_PHC_Software
Manuais
Instalação e Configurações do PHC CS Web

Instalação do Software em Windows

O Software PHC CS Desktop em Windows deve estar corretamente instalado.

Na instalação e manutenção automática, o processo é efetuado sem a intervenção do utilizador. A aplicação verifica se existem alterações às tabelas existentes na base de dados, em caso afirmativo, irá correr a instalação e manutenção apenas para essas mesmas tabelas.

Caso opte pela manutenção personalizada após lida a informação do 1º ecrã, clicar em "Próximo" e no passo "1 de 3" selecionar a opção "Todos";

Clicar em "Próximo"; No passo "2 de 3" clicar todas as opções do ecrã e de seguida em "Próximo";

No passo "3 de 3" é dada a informação relativa à manutenção a ser realizada. Deverá então clicar no botão "Terminar" e avançar para a manutenção.

Em alternativa pode na opção Instalação e Manutenção escolher a opção Atualizar tabela de dicionário de dados para todas as tabelas.

 

Configuração do SQL 

As aplicações PHC necessitam do suporte de um sistema de base de dados. Este, para a PHC, é o Microsoft SQL Server. 

Por ser um software que possui características de tratamento de dados, organização e a sua disponibilização, tem a necessidade de usar grandes quantidades de recursos. Por esse motivo, não é aconselhado que o servidor de base dados seja instalado no mesmo local (servidor) que o IIS. 

Para além de tudo, a compartimentação de valências é algo muito importante para a gestão correta de sistemas de informações. Na queda de um servidor contendo um serviço exposto na internet, levaria tudo atrás (por exemplo o SQL). É conveniente estarem isolados em máquinas diferentes. 

A comunicação entre as aplicações e o SQL é realizado via configuração de DSN (iremos mais à frente ver esta configuração). Devemos garantir os seguintes princípios: 

  • Cada Site / app deverá ter um login próprio. Se possível um login de SQL com acessos apenas de Leitura/ escrita. 

  • Devem ter password aleatórias com mínimo de 15 Caracteres (letras, números, caracteres especiais e maiúsculas / minúsculas) sendo que estas devem ser renovadas periodicamente. 

  • Devemos ter em atenção alguns caracteres que possam interferir no acesso via DSN (Exemplo: “, ‘,@) 

  • É possível que seja necessário que, em condições especiais, possa existir partilha de utilizador (appsettings) entre base de dados. Nestes casos, devemos documentar e realizar auditorias de acessos às BDs. 

  • Se possível estes acessos devem ser por tempo limitado. 

  • Uma boa prática é auditar via Event log os acessos. Podemos para isso criar Filtros no Event Viewer para determinados acessos. 

O SQL, enquanto sistema de gestão de base de dados, permite a encriptação das bases de dados. 

Apesar de ser possível, isto levanta uma série e questões associadas à recuperação, performance e tratamento da informação. 

Para evitar estes handicaps, sugere-se que os discos (ao nível do file system) sejam encriptados. Não é igual, mas se a preocupação é garantir que a informação caso o equipamento seja comprometido (roubado), não seja acessível, então o resultado será idêntico. 

 

O que a encriptação da base da dados irá permitir? 

Caso seja obtido por falha de configuração ou acesso indevido, dados (resultado de queries) da base de dados, o “Atacante” não vai conseguir retirar informação pois ela está num formato ilegível. 

Esta componente é vital em situações nas quais o conteúdo da base de dados coloca em causa a segurança do negócio e/ou pessoas. Deve, no entanto, ser pesada e relacionado com o custo de manutenção dos processos de certificação. Por exemplo numa falha de um sistema na qua a base de dados se encontre encriptada, não basta fazer restore num outro servidor. Toda a configuração relacionada com certificados, tem de ser preparada previamente, pelo que, sim é algo que deve ser implementado, mas apenas quando há a certeza de termos uma infraestrutura redundante, previamente inplace e capaz de transferir a base de dados. Normalmente estas infraestruturas são constituídas com clusters com vários nós nos quais as bases de dados são mantidas. Como o sistema já é operado como um só, uma qualquer falha num servidor encriptado. Não acarreta tempo de preparação de infraestrutura, tornando-se assim exequível. De outra forma o tempo de paragem é muito grande. 

Este tipo de Infraestrutura representa um nível de preparação e manutenção de infraestrutura grande, o que leva a um considerável aumento de custos. Deve por isso ser considerada, mas com atenção a estes argumentos. 

Os acessos às bases de dados são um ponto de falha no que se refere à segurança. Isto porque baseiam-se em passwords. 

O SQL permite que a sua segurança seja associada ao Domínio (caso exista), no entanto isto não é de todo aconselhado. Porquê? 

  • Passamos a ter vários níveis de acesso (validação do domínio e a validação do SQL) 
  • Visto tratar-se de sistemas que estão ligados a serviços externos não devem estar associados a credenciais de domínio. 

Existem ainda alguns Tweeks que podemos usar na configuração do SQL para permitir elevar a segurança e performance. De notar que o “linchpin” do sistema é o SQL. Se este cai, podemos ter toda a infraestrutura de serviços comprometida. Da mesma forma que a otimização do SQL levará benefícios aos restantes componentes da Infraestrutura (IIS por exemplo). 

Algumas das otimizações passam por: 

  • Localização física dos ficheiros do SQL 

    • Master, tempDB, restantes sysDbs devem estar localizadas fora do disco C, se possível, num disco físico à parte. A razão para isto é semelhante à apresentada para o IIS. Se o SQL e estas bds ficarem em causa, o sistema de gestão das mesmas também ficará. Retiramos assim essa componente da equação. O ponto negativo é que a melhor altura para que isto seja realizado é durante a instalação do SQL, pelo que deveremos ter isso em mente no planeamento da instalação do SQL. 
    • Separação física dos MDfs, LDfs das bases de dados. Estes deverão estar separados em discos físicos diferentes. O impacto na performance é muito grande, principalmente para base de dados de uso intensivo. 

    • Separação Física de base de dados. Em casos muito particulares, podemos ter um servidor de SQL a gerir múltiplas base de dados de tamanhos consideráveis e de uso mais intenso. Nestes casos, os processos de escrita leitura dos discos afetam as bases de dados que coexistem no mesmo disco. Deveremos estar assim atentos aos indicadores (existem vários scripts que permitem observar, base de dados a base de dados, o tempo de escrita / leitura em disco), tomando as diligências necessárias para as isolar. 

    • Em caso de situações em que temos servidores virtualizados, é importante que os seus discos (VHDX, VDIs, etc) não compartilhem o mesmo disco físico. É um erro muito comum a aquisição de discos grandes e que até possuam uma velocidade alta de escrita leitura, para colocar neles vários discos virtuais. Exemplificando este erro, um disco físico de 6tb contendo um disco virtual com base de dados de um servidor de SQL e um disco virtual com conteúdos multimédia (Videos) de um filserver, o impacto no SQL durante a copia de um vídeo é enorme. 

    • Escolha de sistemas de RAID. Os discos físicos usados pelo SQL TÊM de estar num qualquer sistema de redundância contra falhas. No entanto o tipo de Raid usado pode provocar alto impacto no processo de escrita/ leitura dos dados. O famoso e muito utilizado Mirror (raid 1) é notoriamente lento na escrita. Claro está que não existe uma regra fixa de qual Raid a usar. Vai depender do tipo de uso dados às bases de dados (mais escrita, mais leitura), tamanho das bases de dados, tipo de discos e sua tecnologia (com ou sem cache), tipo de controladoras e mesmo o Software usado. Dado que esta matéria está constantemente em evolução existem alguns artigos na internet que poderão ser consultados. Exemplos de alguns: § sql raid configuration best practices § https://www.brentozar.com (um dos melhores recursos de scripting sobre SQL da internet) § https://www.sqlservercentral.com 

    • Tempo de vida dos discos físicos. Apesar de ser ignorado pela maioria dos técnicos, os discos têm Tempo de vida previsto, sendo este na maioria das vezes contado em tempo de utilização ou número de processos de Escrita leitura. No decorrer da sua vida útil, a performance dos discos deteriora-se, pelo que é sugerido ter um plano de manutenção que passe pela substituição dos discos. Isso garantirá que a performance é sempre ótima, diminui o risco de problemas, e porque o processo de substituição é acompanhado por um processo de REsync dos raids, trás consigo um processo de reorganização da informação na superfície do disco. Este ponto relacionado com o plano de substituição é ainda mais importante quando temos discos SSD. Enquanto com os discos mecânicos, conseguíamos observar o seu "cansaço” e em caso de falhas até algumas eram audíveis, os SSDs chegando ao número de escritas leituras máximo, simplesmente deixam de funcionar, ou pior ainda se for no caso de áreas do disco, causar corrupção de informação podendo facilmente destruir uma base de dados. 

  • Manutenção das bases de dados 

    • Desfragmentação de índices. O SQL e suas bases de dados são peças quase orgânicas. Ou seja, estão sempre a mudar, transformar-se. Por esse motivo devemos ter atenção na sua otimização, quer das condições onde estas estão inseridas, quer na sua organização interna. Algumas tabelas possuem índices os quais vão sendo desorganizados. Ilustrando, compreendamos os índices como cópias das tabelas ordenados de uma forma diferente. Será como termos várias listas da mesma lista telefónica, umas com ordenação por 1º nome, outras por apelido, outras ainda por número. Dependendo dos Inserts, Updates e Deletes de registos nas tabelas das bases de dados e da sua manutenção, estes índices poderão ficar desorganizados, levando a aumento de tempo na pesquisa. Devemos assim periodicamente realizar manutenções de reindexação / reorganização dos índices. 
    • Atualização das estatísticas. Entre outras coisas, as estatísticas do SQL, são responsáveis por decidirem quais índices serão usados quando percorremos uma tabela para encontrar um registo. Se fizermos uma pesquisa por nome e apelido, existindo dois índices um apenas com o nome e outro com nome e apelido, numa análise muito superficial, podemos dizer que o segundo encontrará mais rapidamente os dados. Ora esta decisão do “execution Plan” é tomada tendo em conta com as estatísticas do SQL. Devemos assim, periodicamente (sugestão diária), realizar essa manutenção. Como sugestão, todas estas manutenções podem ser automatizadas no SQL usando Jobs e o SQL Agent. No caso das versões com menos capacidades/funcionalidade (SQL Express) estes processos terão de ser realizados manualmente. 

Estas operações de manutenção, podem ser otimizadas, usando alguns scripts disponíveis na internet. Um dos melhores locais de Scripting para SQL disponíveis é o www.brentozar.com . Aqui encontrarão uma panóplia muito grande de informação. De notar que todos estes scripts não são patrocinados pela PHC, pelo que deverão ser, caso sejam usados, testados em ambiente de teste. No caso da passagem para produção, esta será da inteira responsabilidade do implementador. 

  • Configuração das bases de dados 

    • Devemos observar alguns cuidados na criação das bases de dados. Alguns passam pela definição do autogrow. Esta configuração é responsável pelo crescimento dos ficheiros de MDF/LDF. O ficheiro é constituído por uma estrutura de páginas, as quais quando vão sendo consumidas pelos dados, e que, quando estas estão perto da sua capacidade, têm de ser criadas novas páginas. O que o SQL faz é arranjar espaço para que esta possam ter lugar. Ilustrando, o SQL cria uma caixa vazia com x espaço (MDF). Sobre este espaço vai associando as páginas com os dados, até ao momento que não possui mais espaço livre, necessitando de crescer a caixa. Este crescimento está relacionado com a configuração do autogrow. Imaginemos que está a 10 % e o tamanho atual são 100mb, o sql iria aumentar o MDFs em 10mb. O problema é que todo este processo é bastante intensivo do ponto de vista de recursos, pelo que deve ocorrer só nas vezes estritamente necessário. Por esse motivo deve estar em percentagem (Sugerimos entre os 10 e os 20 %). 
    • Recovery Model. O recovery model é importante para a otimização base de dados de um modo indireto. Para compreender o que é o recovery model, ilustramos como os processos de escrita na base de dados é realizada. Os dados não são escritos, quando inseridos no SQL, diretamente no MDF. Estes são escritos no Log (LDF) associados à base de dados e, em determinados momentos, transferidos para os MDFs. Ora, conforme a configuração da base dados (Full, simple, bulked) este processo pode ser mais rápido ou mais espaçado no tempo. Isto leva que o Disco onde estão a ser escritas as informações terá uma taxa de desfragmentação maior, as pesquisas terão de ser realizadas em dois locais diferentes. Por outro lado, se tudo estiver no MDF, o impacto no SQL é realizado de outro modo. Esta definição deve ser pensada, pois até impacta na forma como os backups são realizados. 

  • Compatibility level da base de dados. O modo de compatibilidade da base de dados está associado a 2 fatores: 

    • A versão do Servidor onde a base de dados está a operar 

    • A versão do servidor onde a base de dados foi criada. 

Como regra, o modo de compatibilidade deve estar sempre na última (mais recente) disponível pelo servidor e compatível com as indicações da PHC. Mas afinal o que é o modo compatibilidade? É simplesmente o toolbox de instruções que podem ser usadas quer funções do SQL, formas de gestão da base de dados etc. 

  • Autoclose. Deve estar sempre a falso. Na prática estando ativo, o sql "para a base de dados sempre que nota que não existem conexões a ela. O problema é que o tempo de “reativação" da base de dados é sempre grande. Só poderá ser justificável em sistemas pequenos e de poucos recursos. 

  • Auto create Statistics. Deve estar a true. Falamos nas estatísticas em tópico em cima. 

  • Auto Srink. Deve estar a false. Esta opção está associada ao que é produzido com a “Caixa” que falamos em cima. Na verdade, o que faz é tentar otimizar o espaço livre em disco, reduzindo o espaço vazio no MDF, obrigando o processo continuo do SQL de “autogrow /Autosrink”. É péssimo para a performance, unicamente devendo ser usado quando as restrições no espaço físico de disco é algum impossível de endereçar de outro modo. 

Uma necessidade das áreas de gestão do SQL, é a auditoria das interações com o servidor de SQL e suas bases de dados. 

Recomenda-se que seja criado um trace log permanente de tudo o que é realizado. Isto é vital para análise forense caso existam problemas, detetar pontos de falha, pois estes logs podem ser tratados por parsers, procurando por determinados sinais, ou mesmo analisados para detetarem botlenecks (tempo de execução de uma query, número de reads, Writes, etc). 

A forma mais simples é ativar o SQL Server Profiler, numa máquina externa ao SQL. Este durante o processo de captura do traces usa bastantes recursos de memória, pelo que não devemos criar esta pressão no servidor. 

Devemos ter atenção na sua configuração. Facilmente criamos verdadeiros “monstros” de GB de disco, se não tivermos atenção às opções selecionadas. 

  • Sugerimos assim um trace que aborde: 

  • Errors and Warnings: CPU Threshold exceeded e User Error Messages 

  • Security audit: Audit Login Failed 

  • Store Procedures: RPC: Completed, SP:StmtCompleted e SP:StmtStarting 

  • TSQL: Exec prepared SQL, SQL:BatchCompleted, SQL:StmtCompleted e SQL:StmtStarting 

  • Transactions: TM: Rollback Tran Completed e TM: Rollback tran Starting Estes indicadores, deverão ter todas as colunas de seleção preenchidas. 

 

De notar que estes indicadores são apenas alguns. Na verdade, estão balanceados entre o número de registos que geram em ficheiro com a quantidade de informação que podemos retirar deles. Muitos outros podem ser escolhidos se pretendemos ter uma abordagem de analise mais fina. 

Será da escolha do administrador realizar a melhor seleção para o propósito pretendido. 

Como foi indicado anteriormente este tipo de traces gera uma quantidade enorme de dados. 

Devemos por isso usar um local de destino destes externos ao SQL. Recomendamos que sejam produzidos sobre a forma de ficheiros (apesar de poderem ser incluídos em base de dados diretamente, estas rapidamente tomam tamanhos gigantes. Da experiência, uma localização partilhada na rede com ficheiros a fazerem rollover é a melhor solução. 

Sugerimos assim, ficheiros não mais que 256 Mb com rollover automático. 

 

  • Criação dos Utilizadores

Utilizadores SQL

Conforme o tipo de aplicação que se pretende instalar, devem ser criados os respetivos utilizadores SQL:

  • Tipo de Aplicação: Pública - Nome do Utilizador: Público
  • Tipo de Aplicação: Interna - Nome do Utilizador: Interno
  • Tipo de Aplicação: Externa - Nome do Utilizador: Externo

 

Estes utilizadores já vão configurados no ficheiro appSettings.config com os nomes anteriormente indicados. Se quiser alterar pode fazê-lo e neste caso deve alterar a seguinte chave: add key="DSN" value="server=A;uid=B;pwd=C;database=D;"/

Em que B deve ser substituído pelo nome do utilizador criado e, no caso de ter configurada uma password esta deve ser indicada em C.

  • Aplicações internas (Intranet): No caso de estar a instalar uma aplicação interna, os utilizadores são criados no menu Sistema na opção Utilizadores. Qualquer utilizador normal do Software em Windows pode ter acesso às aplicações PHC CS Web, basta para tal na página PHC CS Web escolher a opção Tem acesso via PHC CS Web. Os utilizadores têm acesso por Package, isto é, o Software apresenta a listagem de todas as aplicações internas, mas o utilizador pode só ter acesso a uma delas. Neste caso deve ser passado o nome da aplicação para a janela do lado direito.

 

  • Aplicações externas(Extranet): No caso das aplicações externas, os utilizadores são criados no módulo Supervisor, na opção Utilizadores de Clientes. É ainda necessário na ficha do cliente, na opção de menu Utilizadores deste cliente - PHC CS Web e na página Outras opções do Cliente escolher as aplicações que o cliente adquiriu.

 

Configuração do IIS 

A configuração apresentada visa as vertentes de garantir um servidor de IIS capaz de permitir a evolução no que se refere às tecnologias usadas de desenvolvimento, capacidade de auditoria e isolamento das aplicações e Sites Instalados. Pressupõe que estes se encontram numa DMZ controlada por uma firewall. 

Durante a instalação do Sistema Operativo uma das componentes será a instalação do servidor Web (IIS). Uma nota importante: 

  • Se o sistema operativo for Windows 2019, devemos antes de iniciar a instalação dos roles e Features, instalar primeiro o .Net Framework 4.8. Este requisito deve-se a uma limitação do SO quando selecionarmos os componentes do .Net 3.5. 

 

Para isso, contamos com as opções acessíveis via ServiceServer Manager que se encontram separadas entre Roles e Features. 

 

Os Roles representam os “serviços” que o servidor irá disponibilizar. Neste caso, e como estamos a tratar de um servidor para disponibilizar aplicações Web, vamos instalar os “Roles” associados a estas valências. 

 

 

Clicando em Manage, temos acesso às configurações dos componentes. Para os configurar, selecionámos “ADD Role and Feature”. 

Aqui, ativamos a opção: 

  • Web Server (IIS) 

 

A aplicação vai questionar se pretendemos adicionar os pacotes (features) de Gestão pelo que indicamos que sim. 

 

Fazemos Next e passamos às features. Nas features vamos personalizar quais as opções que o o nosso servidor deverá possibilitar configuração. Assim devemos selecionar: 

 

  • Roles Services 

 

Notas importantes: 

  • Em alguns dos componentes (Roles e features), existem opções que estão previamente marcadas. Outras, teremos de as confirmar. Assim, e para garantir que todas as opções aqui apresentadas estão confirmadas, devemos abrir todos os nós. 

  • Nas opções ativadas que apresentam a necessidade de instalação de outros componentes (herança) devemos confirmar sempre. 

Após a instalação, podemos iniciar a configuração das aplicações CS Web.

 

Instalação do IIS (Internet Information Services)

No painel de controlo do Computador, opção Adicionar/Remover Programas tem de escolher a opção de Adicionar/Remover Componentes do Windows para instalar o IIS. Este componente vai ser instalado por defeito em: C:\Inetpub

Se ao instalar a aplicação encontrar um problema, a solução passa por aceder ao Painel de Controlo, Programas, Turn Windows features on or off, e definir as seguintes configurações:

 
 

Instalação da Aplicação

No CD de instalação, existe uma diretoria chamada 'Aplicacoes', dentro desta diretoria, existem as pastas com os nomes das aplicações e dentro de cada está um ficheiro zip.

- Para instalar o PHC CS Web é necessário ter o Web Pllaform Instaler (Deploy) instalado no IIS.

- Para instalar pode efetuar o download em http://www.iis.net/downloads/microsoft/web-deploy, ou no Cd de instalação na pasta Outros/ deploy, correr o setup.

 

No web Plaftorm installer 4.6 no separador "produts" proceder à instalação do Web Deploy 3.5.

No IIS, no Default Web Site efetuar clique direito e escolher a opção, deploy - Import application. O processo de instalação da aplicação passa por efetuar os seguintes passos:

1 - Selecionar o caminho onde se encontra o ficheiro da aplicação, por exemplo, "Intranet.zip".

2 - Na instalação surge os ficheiros que vão ser instalados. Não desseleccionar nenhum.

3 - O próximo passo devemos indicar qual o nome que pretendemos dar ao nosso projeto PHC CS Web

4- Ao clicar em next, será instalada a aplicação.

 

Poderá da mesma forma, instalar a aplicação da seguinte forma:

Poderá também, instalar a aplicação, ou atualizar o projeto do PHC CS Web de uma forma automática:

Podemos copiar os ficheiros da aplicação, que pretendemos instalar, para uma diretoria.

Dentro da pasta de PHC CS Web, no ficheiro intranet.setparameters.xml, editamos o ficheiro e colocamos o nome do projeto que pretendemos, dar exemplo: setParameter name="IIS Web Application Name" value="Default Web Site/intranet"

Abrir o Command prompt (como run as administrator) colocar o seguinte caminho (Exemplo): Cd:C:\XPTO \intranet\intranet.deploy.cmd /y

Ao correr este ficheiro vai efetuar a instalação e criar o projeto com o nome que foi dado no intranet.setparameters.xml.

E para que seja um processo automático poderá criar um bat.file com as seguintes configurações, efetuando os seguintes passos: @echo off

C:\intranet\intranet.deploy.cmd /y

Desta forma, cada vez que for necessário proceder a alguma atualização, basta correr o bat.file. Como fazer um bat.file

Abrir um ficheiro Notepad e gravar o mesmo com extensão de .bat , editar o ficheiro e colocar a informação acima indicada.

A aplicação que instalou fica, por defeito, na seguinte diretoria: C:\inetpub\wwwroot\NomeDaAplicacao.

Se não estiver neste local é porque o IIS (Internet Information Services), não foi instalado em c:\inetpub, neste caso, terá que verificar qual o caminho para a diretoria do IIS.

Se utilizar o IIS7 deve aceder ao mesmo, selecionar a aplicação que acabou de instalar e efetuar clique direito sobre a mesma. Selecionar a opção "Manage Application" e depois a opção "Advanced Settings".

O IIS vai abrir um ecrã de configurações avançadas onde se deve clicar no botão relativo ao Application Pool.

 

A aplicação volta a abrir um ecrã no qual se pode observar a versão da Framework relativa à Application Pool selecionada. Deve estar selecionada a versão a 4.5.

De forma a melhorar o desempenho em termos de rapidez do PHC CS Web devem ser efetuados os seguintes passos no IIS:

  • Aceder às Application Pools e selecionar a application pool utilizada pelo PHC CS Web;
  • Aceder às "Advanced Settings..." e selecionar as seguintes opções:

- Start Mode: AlwaysRunning

- Idle Time Out Action: Suspended

- Maximum worker processes: 0

Depois das alterações é necessário fazer o "Recycling..." da application pool.

Feitas estas verificações deve continuar a instalação da aplicação.

Após a instalação, podemos iniciar a configuração das aplicações CS Web.

 

Configuração dos Logs 

Uma das componentes importantes para a segurança de sistemas, é a capacidade de auditar as comunicações, os acessos, a receção e envio de informação. 

Para isso devemos configurar um local onde todos estes registos ficam armazenados e podemos ser consultados. 

Para isso, existem três registos importantes: 

  • Registos de Sistema: Eventlog 

  • Registos de acessos / comunicações com o IIS 

  • Registo de comunicações do servidor de SMTP (quando instalado) 

 

Os registos de eventlog são muito importantes para a avaliação de indicadores de saúde do sistema. Está dividido em três áreas principais para as quais devemos olhar: 

  • Applications: 

    • Devemos ter em atenção a eventos com a Fonte – WAS. Estes eventos estão associados com as application pools associadas ao IIS. Devemos ter em atenção a mensagens associadas a VSS ?? WAS ??, Restart Manager e performance counters. 

  • Security: 

    • Este tipo de Log concentra avaliações / erros de acesso ao sistema. Qualquer erro recorrente de acesso poderá ser um alerta para uma tentativa de acesso ilegal ao sistema ou de uma funcionalidade/app mal configurada. De qualquer forma, deverá ser o mais urgentemente validada. 

  • System: 

    • Talvez o log mais importante do SO. Devemos sobre este ter em conta logs de Fontes como “WAS” (Associadas ao IIS e suas aplicações), “ServiceServer manager” (associada a serviços do Sistema Operativo entre os quais o IIS), Kernel (associadas a sistema) 

 

É também importante observar os registos de acessos aos sites e apps. 

Para isso, o servidor de IIS pode produzir um conjunto de Logs que registam as comunicações e para as aplicações alojadas nele. 

No entanto, para que seja possível reduzir a pressão destes logs no sistema operativo, é conveniente que se crie um diretório num disco exterior ao Disco C. 

 

Assim, criámos um Diretório para armazenar Logs. Por exemplo, E:\Logs. 

 

Neste criámos um subdiretório para os logs de IIS. Desta forma, podemos configurar o IIS. Para isso, aceda ao IIS Manager, clique na raiz da árvore (link com o nome do Servidor). Encontrámos um shortcut associado aos logs. Acedendo ao “logging”, conseguimos configurar a forma como desejámos realizar os logs. 

 

Sugerimos:

 

Devemos ter em conta os campos registados. Sugerimos que todas as opções estejam ativadas. 

 

Uma nota adicional, é o tipo de log. Este deve ser por server. Isto, porque caso seja definido por site, apesar de se compartimentar os logs, a sua pesquisa e gestão torna-se muito mais difícil. 

 

Por último, resta os logs do SMTP Server. 

 

No momento da instalação, podemos verificar que instalámos o Servidor de SMTP. De notar que a origem deste servidor foi uma forma de dotar a capacidade de enviar email aos webmasters. Não dever por isso ser usado como método de envio de email (apear de ser passível de usar dessa forma). 

 

Porquê? 

As comunicações por emails foram das maiores conquistas de aproximação / partilha de informação originadas nesta evolução tecnológica. No entanto, todos sabemos os malefícios desta mesma partilha / facilidade de comunicação. Spam, Phishing entre outros malefícios atribuiu uma nota de desconfiança a este forma de comunicação. 

 

Para contornar estes malefícios, a indústria começou a criar uma série de salvaguardas sobre a forma de email securities, content filters, RBL’s etc. Por esse motivo, um uso excessivo sem controlo deste tipo de servidor, pode facilmente colocar um domínio / IP em Blacklist, ou pior, gerar uma perda de reputação do domínio causando perdas que podem ser consideráveis de Dinheiro. 

Para minimizar esta situação devemos configurar o servidor de smtp da seguinte forma: 

  • Aceder a Internet Information Service (IIS 6.0)

 

A primeira ação é definir, tal como o IIS, a localização dos Logs e o nível de logs, configurando as variáveis que serão armazenadas: 

 

Tal como no IIS, devemos ativar todas as opções. Dessa forma, podemos analisar os logs de diversas perspetivas. 

 

Configuramos agora, quem pode aceder ao servidor. Estes servidores de SMTP não devem permitir que sejam acedidos externamente, nem mesmo de computadores da mesma rede. Caso estes fiquem comprometidos, poderão usar o servidor como uma porta de envio de informação sem qualquer controlo. 

 

O mesmo se passa com a possibilidade de relay. Este deve ser o mais controlável possível, pelo que apenas colocamos o IP do servidor. 

As restantes configurações podem ficar como estão. Nota adicional para os seguintes pontos: 

  • Não alterámos a localização do Badmail. Na verdade, por defeito, este diretório que armazena a coleção de email e seus NDRs está no Discos do sistema operativo. 

No entanto, juntamente com este diretório existem outros (queue email, pickup e drop mail). Todos estes diretórios encontram-se no mesmo local, pelo que alterar esta informação seria espalhar a informação. Devemos, por isso, ter alguma atenção a estes diretórios. 

 

Configuração da Alarmística 

A gestão de servidores expostos na internet é algo vital para a boa manutenção dos serviços que são lá executados. O abandono destes princípios de cuidado, podem colocar em causa a reputação de uma empesa. 

Por esse motivo, o uso de Software que visa criar uma base de dados de análise e alerta de ocorrências que saem fora do que é padrão é essencial. 

Existem vários, (Zabbix, Spiceworks, Diversos softwares da Microsoft agregados em Azure pelo Sentinel). No entanto e independente do usado, o importante é que observem os seguintes princípios: 

  • Criem histórico: A análise de alarmística é tão ou mais importante o histórico que a ocorrência localizada. Exemplificando, um acréscimo de Hits num site a determinada hora durante vários meses, é diferente de um acréscimo de hits numa mesma hora quando isso não é normal. A Segunda pode ser um ataque, a 1ª uma ocorrência normal originada num processo de início de backup por exemplo. 

  • Possibilidade e Alarme: Deve ter a capacidade de alerta em vários suportes (email, sms, etc), quando algo não está bem. 

  • Configurável: Os falsos positivos são uma constante. A Capacidade da plataforma pode ser programada / configurada para tornar mais fina a malha na qual alertar de problemas deve ser um requisito. 

 

Utilizador ASPNET

Aquando da instalação da Framework, é criado no sistema um utilizador chamado ASPNET, este utilizador deve ser passado para o grupo dos Administradores locais da máquina, este procedimento é temporário para o arranque da aplicação, pois este utilizador só deverá estar neste grupo (Administradores) durante o arranque das aplicações PHC CS Web. Assim que todas as aplicações tenham sido executadas com sucesso pela 1ª vez, deverá o mesmo ser removido do referido grupo. Esta situação é necessária para que sejam (no 1º arranque bem sucedido) criados no event viewer os logs de cada aplicação.

Só é necessário este passo se a key do appSettings estiver com o valor Sim.

 

Instalação do IduServer

O IduServer é um aplicativo que está no cd de instalação e que deve ser instalado para quem precisa de impressões de idus em pdf nas aplicações PHC CS Web. As impressões em idu estão disponíveis nas seguintes tabelas: BO, FT, RD, FO, PE, RE, CL, PA, MH e PR. Existe ainda uma configuração appSettings no ficheiro appSettings.config, de nome <add key="SMTPSERVER" value="localhost "/>, essencial para que esta impressão funcione.

Se após instalação deste setup ocorrer um erro na aplicação ao imprimir idêntico a este: "Erro IDU: Não foi possível inicial a aplicação de impressão." e "Erro IDU: Retrieving the COM class factory for component with CLSID {C05B3535-FA4F-4CBD-B3EA-AE999AD66101} failed due to the following error: 80040164", significa que o setup não conseguiu registar o ocx na máquina, neste caso deve registar à mão o seguinte ficheiro: iduserver.dll.

Poderá fazê-lo da seguinte forma: regsvr32 c:\inetpub\wwwroot\iduserver\iduserver.dll

Dica: Deve instalar o iduserver na diretoria proposta pelo setup.

Nota Importante: Caso já tenha uma versão anterior instalada é necessário desregistar a dll da versão anterior e efetuar o registo da nova dll.

 

Configuração do ficheiro appSettings

No local da instalação fica um ficheiro chamado appSettings.config.

Este ficheiro é muito importante pois é nele que existe muita da informação necessária à aplicação para que esta seja executada.

Nota: Este ficheiro é Case Sensitive, isto quer dizer que, por exemplo, On é diferente de on e nos casos de enganos as instruções não são lidas.

 

Entrada na Aplicação

Após a configuração do ficheiro appSettings a aplicação está preparada para arrancar, para tal basta no browser fazer:

Localhost/nome da aplicação [enter] (no caso do servidor local)

Nome do servidor/nome da aplicação [enter]

Nota: Depois de entrar uma vez na aplicação, deve retirar o utilizador ASPNET do grupo dos administradores.

 

Re-arranque da Aplicação

No caso de ser necessário re-arrancar a aplicação, é possível fazê-lo de diversas formas:

- alterando a chave do "ENOME" que se encontra no ficheiro appSettings.config e posteriormente, reiniciar o IIS (Internet Information Services);

- executando o comando: iisreset, na linha de comandos do DOS;

- através das opções de configuração acedidas pelo comando: ../programs/gensel.aspx?opcoes=sim (opção Re-arrancar a aplicação); ou

- re-arrancando o computador.

Dica: O PHC CS Web demora mais de 30 segundos a arrancar de cada vez que um utilizador entra no software após este ter sido arrancado. É o momento em que o sistema compila a aplicação. Assim, para evitar que isto aconteça a outros utilizadores, sempre que arrancar a aplicação, entre na aplicação para que esta faça a compilação inicial.

 

Configuração de certificados 

Abordamos nuns tópicos em cima, a questão da reputação. A reputação de um domínio / serviço é algo importante, até porque os utilizadores estão cada vez mais informados, atentos e cuidadosos aos serviços que usam ou consomem. Por esse motivo, a necessidade de os descansar é essencial. 

O uso de certificados é primordial. 

Os certificados trazem duas principais capacidades: 

  • A encriptação da informação 

  • A Certificação da entidade que está a fornecer o serviço 

 

A transferência de dados entre dois pontos, seja na cópia de ficheiros, seja no simples acesso a uma página de um qualquer site, é passível de ser escutada, capturada, podendo assim ser visualizada ou pior alterada. A associação de um certificado ao servidor é por isso muito importante. 

Por outro lado, a certificação da entidade é também importantíssima. Se para a comunicação, um certificado “Gratuito” tipo Lets encript ou outro será suficiente, para a autenticação da entidade já é mais difícil sendo necessário um certificado obtido numa entidade certificadora credenciada. 

A Explicação é simples: Ninguém confia numa fechadura cuja origem não conhecemos. É o mesmo para os certificados. 

O âmbito do certificado é também de relevante importância. Um certificado pode ter uma ou várias valências podendo certificar um domínio, comunicação de email, código fonte etc. 

Para os sites deve ser adquirido um certificado para múltiplos Alias/subdomínios, normalmente chamados Wildcard, p.e., *.Domínio.pt. 

Desta forma, podemos associar vários sites ou apps sobre um mesmo domínio (Exemplo: Intranet.dominio.pt; Extranet.dominio.pt) 

A instalação de um certificado normalmente é feito via duplo clique sobre o certificado (No caso do IIS o ideal é estar em formato PFX), e seguir os passos.

Devemos ter em conta que: 

  • O certificado deve ser instalado em Local Machine; 

  • Não se deve instalar a chave privada no servidor; 

  • Não se deve permitir a exportação; 

  • Deve ser instalado por defeito usando a opção “Automatically select the certificate store based on the type of Certificate”; 

  • O ficheiro uma vez instalado, deve ser apagado do servidor; Com o certificado instalado, podemos configurar os sites com HTTPS.

 

Instalação das aplicações CS-Web 

As aplicações são agora instaladas de forma muito mais automatizada. A PHC via Setup de instalação facilitou muito o trabalho técnico de configuração. No entanto, existem alguns pontos que poderemos otimizar garantindo um maior nível de segurança das aplicações. 

  • Já abordado anteriormente, a localização dos sites / Aplicações, deve ser externa ao Disco C. No entanto, o diretório do Inetpub e Wwwroot não deve ser alterado. A razão é a já mencionada. Se colocarmos todo o impacto das apps no disco c (do sistema) ele próprio poderá ficar sobre esforço caso um ou vários sites fiquem com algum problema (excesso de tráfego, ataque, …). Se isto ocorrer e afetar o acesso ao disco (por estar por exemplo muito ocupado) vamos ter dificuldade em agir pois poderemos no limite não ter acesso a consola. 

  • Outro ponto é o crescimento. Podemos ter múltiplos sites, crescendo estes também em tamanho. Isto irá causar pressão por exemplo na quantidade de disco disponível para memória virtual. O que fazer? 

 

* Num disco à Parte do Servidor criar uma pasta vazia Exemplo: Sites 

  • Retirar desta pasta a herança dos acessos 

  • Atribuir a esta pasta acessos ao user IIS_IUSR de full control (replicada na sua estrutura para diretórios e ficheiros) 

  • Criar uma Application pool por cada Site / app:

  • Este ponto é muito importante. Desta forma, podemos interagir (recycle parar) cada um dos sites / apps sem por em causa os restantes. 

  • Por template, os sites e apps são colocados no Default website. A sua application pool só deverá conter 1 app (ele próprio). O Default web site é muito mais que um site pois é ele que “coordena “ todo o servidor. Se cair, ficar instável, teremos muito provavelmente de reinstalar o servidor. 

 

Cada App pool tem um conjunto de recursos / configurações que podem ser personalizadas. Alguns devemos alterar para maximizar o performance do servidor: 

  • Start Mode – para sites / apps internas com perfil de uso médio deve ser colocado em ondemand. Se forem sites externos então em allwaysRunning 

  • CPU 

    • Limit: Este parâmetro deve estar relacionado com o número de sites existentes no servidor bem como o seu perfil. Como” regra de polegar”, 80% por mais de 5 m algo vai ficar mais lento. No entanto não existe regra fixa. Deverão ser testados e ajustados 

    • Limit Action: Se estivermos com as apps pools configurados para darem o máximo até os recursos se esgotarem, o melhor é mesmo uma ação de Killw3wp. Isso irá matar o processo da app poll libertando os recursos, 

    • Limit Interval: Tempo associado à % máxima de CPU (Ex: 90% de Cpu durante 5 minutos) 

 

* Process model 

  • Identity: este parâmetro indica em que contexto de segurança a app pool executa o Site. Caso esteja em applicationpoolIdentity, todos os processos da aplicação serão executados sobre um “Falso” user com o nome da application pool. Isto permite isolar recursos das outras application pools. 

Recomendamos esta opção. 

  • Idle Timeout: No caso de sites de uso inconstante, os 20 m padrão é suficiente. O que este parâmetro indica é que ao fim de 20 minutos de inatividade do site, este liberta recursos e desliga-se. Permite assim que os recursos cativos, possam ser usado por outras aplicações. 

  • Idle Time-out action: Por padrão a opção encontra-se em Terminate. No entanto nos casos de sites que não são usados regularmente mas precisam que sejam iniciados rapidamente, a melhor opção é Suspend. Dessa forma eles libertam parte dos recursos, mas ficam num estado que na 1ª chamada seguinte acordarão rapidamente sem levar o tempo normal de arranque de um site. 

 

* Recycling 

  • Specific Times: Neste parâmetro é possível configurar os momentos em que a application pool faz recycle. Em sites internos com muito uso (exemplo Intranet) poderá ser aconselhado o recycle por exemplo de madrugada. Desta forma quando os utilizadores necessitarem de entrar na aplicação estas já se encontram disponíveis. 

 

As aplicações Web possuem 2 ficheiros de configuração principais a ter em atenção: 

· Web.Config 

· Appsetting.config

 

Na verdade, o Appsettings.config é uma parte do web.config. No IIS, quando se altera o conteúdo do Ficheiro Web.config, a application pool faz automaticamente recycle. A PHC para evitar esta funcionalidade do IIS, extraiu destes a componente de configuração das aplicações (Appsettings.config). 

O web.config é o ficheiro de configuração das apps / sites. Nele ficam descritos as configurações associadas por exemplo a Frameworks, redirects, regras de Url Rewrite, apresentação de erros, configurações de segurança, etc. 

 

Alguns destes são de alteração opcional com o objetivo de otimizar a segurança e performance. Usando alguns addons ao IIS tal como URL Rewrite, podemos configurar regras para forçar o HTTPS. 

Para isso precisamos de ter os sites associados a um certificado (ponto já anteriormente visto) e possuir uma regra que quando o utilizador faça um http:\\Site.tld seja redirecionado para Https://Site.tld

 

Garantimos assim uma maior visibilidade ao site pois admite http e https sem comprometer a segurança. 

 

Como fazemos isso? 

 

  • Colocando a chave 

<configuration> 

<system.webServer> 

<rewrite> 

<rules> 

<rule name="HTTP/S to HTTPS Redirect" enabled="true" stopProcessing="true"> 

<match url="(.*)" /> 

<conditions logicalGrouping="MatchAny"> 

<add input="{SERVER_PORT_SECURE}" pattern="^0$" /> 

</conditions> 

<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" /> 

</rule> 

</rules> 

</rewrite> 

</system.webServer> 

</configuration> 

 

(Notar que as Chaves podem já existir. Deverá ser previamente confirmado e usado o exemplo como matriz. 

 

  • Outro ponto é a apresentação de erros. No webconfig existe uma chave 

    • <customErrors mode="RemoteOnly"> 

    • <error statusCode="404" redirect="programs/gensel.aspx?erro=404"/> 

    • <error statusCode="403" redirect="programs/gensel.aspx?erro=403"/>

    • </customErrors> 

 

Esta (“Mode”) deve estar a On (Case Sensitive), sendo que deveremos ter uma página de redireccionamento / manutenção em caso de mensagem de erro. Desta forma o comportamento do Servidor é sempre constante, esteja em falha ou a correr, reduzindo a possibilidade de existir uma abertura para ser explorada. 

  • Outras configurações como costumheaders, serverheaders, as quais transitem informação sobre sites e servidores, podem ser removidas / personalizadas. No entanto isto deve ser realizado em conjunto com o desenvolvimento da aplicação, estando neste momento, a decorrer procedimentos para limitar a sua ação. 

 

No que se refere ao Appsettings.config existem alguns cuidados que podemos ter para garantir uma maior segurança. 

  • Não ter mais chaves que a quelas que são necessárias. Há muito a ideia que podemos copiar um Appsettings.config de uma app para outra. Isto até é verdade, mas a informação que é transportada para ele, além de ficar em ficheiro separado, torna confusa a gestão das configurações. Por esse motivo, e apesar de ser trabalhoso, devemos apenas ter a informação que seja necessária e esteja atualizada. 

  • Tags associadas a email, contas e passwords, devem ser únicas por sites. Assim isolamos a origem e podemos facilmente alterar a password, sabendo onde ela está a ser usada 

  • Ter atenção às tags de OnError, logerr, loglogin. Apesar de sugerido que estejam ativos, geram alguma informação, a qual terá de ser limpa manual e periodicamente. Estes logs contem informação interna e não devem ficar disponíveis duram longos períodos. 

 

Falta ainda falar nos bindings. 

Os sites possuem bindings (ligações a Ips). Isto porque no inicio cada site teria de ter associado um ip único externo. Já não é assim (à já algum tempo). Isto provocava que para cada ip só poderíamos ter um site por Ip/ porta (Ex: http://site.tld associado ao Ip AAA.BBB.CCC.DDD porta 80. Poderíamos ter outro site para o mesmo Ip mas para outra porta (Ex 81)) 

Atualmente podemos ter todos os Sites associados à Mesma porta. O IIS Fará as alterações automaticamente. 

 

Para isso configuramos nos bindings 

Para configurar estas ligações, podemos associar várias portas ao mesmo site / serviços. Configurando o Hostname a qual ele vai responder, o IIS redirecionará a comunicação para o local correto. 

 

Exemplo: o IP 111.111.111.111 Está disponível para um servidor de iis. A este poderemos associar os sites: 

 

 

Como fazemos isso? 

No ecrã de Bindings associámos o tipo de protocolo (associado a uma porta), Hostname, que será o site sem o prefixo. Criámos assim uma base de dados de Bindings 

No caso de serem HTTPS, teremos de associar um Certificado (já anteriormente visto) e no caso do Windows 2019 podemos e devemos configurar para que não sejam aceites certificados com Chaves Fracas. 

 

Geral.css e User.css

Existe um ficheiro de configurações chamado geral.css, este ficheiro aquando da instalação da aplicação é colocado na diretoria CSS.

É no ficheiro de configurações geral.css, que estão definidos os formatos genéricos de toda a aplicação, sendo principalmente tamanhos, margens e alinhamentos.

Existem alguns CSS que permitem a definição das cores em função do tema cromático escolhido pelo utilizador, sendo os seguintes:

- Theme-default.css- Onde estão as definições do tema "Normal"

- Theme-classic.css - Onde estão as definições do tema "Cor"

- Theme-dark.css - Onde estão as definições do tema "Escuro"

- Theme-4.css - Onde estão as definições do tema "Aqua"

- Theme-5.css - Onde estão as definições do tema "Glaciar"

- Theme-6.css - Onde estão as definições do tema "Anil"

- Theme-7.css - Onde estão as definições do tema "Coral"

- Theme-8.css - Onde estão as definições do tema "Prado"

- Theme-9.css - Onde estão as definições do tema "Branco"

 

No caso de se pretenderem alterações, por exemplo às cores, estas devem ser feitas no ficheiro chamado user.css, que se encontra na diretoria PIMAGES e que fica vazio aquando da instalação. Não são aconselháveis alterações ao geral.css.

Existe um ficheiro para cada tema onde é possível pode sobrepor as definições de cores ao seu gosto:

- Pimages/user1.css para o tema "Normal"

- Pimages/user2.css para o tema "Cor"

- Pimages/user3.css para o tema "Escuro"

- Pimages/user4.css para o tema "Aqua"

- Pimages/user5.css para o tema "Glaciar"

- Pimages/user6.css para o tema "Anil"

- Pimages/user7.css para o tema "Coral"

- Pimages/user8.css para o tema "Prado"

- Pimages/user9.css para o tema "Branco"

 

Ficheiro App_Offline.htm.txt

O ficheiro App_Offline.htm.txt, que é instalado com o PHC CS Web, permite desligar temporariamente o site.

Quando se pretende, por exemplo, efetuar manutenção do site, basta renomear o ficheiro para App_Offline.Htm passando a surgir a informação de que o site se encontra temporariamente indisponível.

Para voltar a colocar o site disponível, ou seja, voltar a ligar, basta renomear o ficheiro para app_offline.htm.txt.