Re: [sbis_l] Re: NGS1.07.11 - Todos os dados do RES devem ser segregados por organização, ou seja, nenhum dado do RES de uma organização pode ser acessado ou visualizado por usuário de outra organização.

Luciano e Flavio,

vocês tem toda razão em estarem preocupados com questões de segurança e privacidade em nuvens computacionais, e isso não se restringe apenas ao cenário de saúde. Quando alguns alunos me perguntam se cloud é seguro eu respondo que é como voar no Triângulo das Bermudas em um avião monomotor, é muita emocionante, mas em compensação...

Com relação a criptografia, na minha opinião, de cara existem dois pontos "críticos". Primeiro: enquanto a informação estiver criptografada tudo bem, ela está "segura", mas como vocês fazem para proteger as chaves criptográficas? Se eu tiver que atacar um criptossistema a primeira coisa que vou tentar fazer é roubar uma chave criptográfica, pois a probabilidade disso dar certo é maior que a de quebrar o algoritmo/protocolo matemático. Além disso, se existem muitas chaves criptográficas acaba ficando custoso e complexo gerenciar tais chaves.

Segundo ponto: a informação não vai ficar criptografada para sempre, em algum momento (na nuvem?) ela vai ter que ser decriptografada por algum motivo. E é aí que mora o perigo, pois neste momento a informação fica vulnerável e eu tenho mais uma brecha/chance para atacar.

A promessa dos criptógrafos para resolver o problema de segurança, que é o calcanhar de Aquiles, das nuvens é a criptografia homomórfica. Os sistemas criptográficos parcialmente e completamente homomórficos tem apresentado avanços significativos ano a ano, porém acredito que ainda vai demorar um pouco para tornarem-se realmente aplicáveis em contextos práticos reais. Para vocês terem uma ideia um destes algoritmos (que não recordo o nome no momento) precisava de uma chave de 600 KB. Para efeito de comparação o RSA hoje em dia trabalha com chaves de 2048 bits (se já não mudou).

Como não podemos ficar esperando pela criptografia completamente homomórfica eficiente, alguns pesquisadores do mundo (incluindo eu) estão apostando suas fichas em Computação Segura entre Duas (ou Múltiplas) Partes. Pois acredita-se que seja um caminho com soluções de segurança que possa ser desenvolvido em menos tempo.

Ah se eu tivesse mais tempo para dedicar ao estudo desses assuntos. Mas apenas estudar não é muito lucrativo, então tenho que trabalhar. O jeito é fazer como o Albert Einstein e pesquisar nas horas vagas.

Abraços,

Eduardo Takeo

Em 27 de maio de 2014 11:40, Flavio Barbosa (CIAware) <flavio2020@gmail.com> escreveu:

Bom dia.

Marcelo eu concordo com o Luciano, o paciente deve bloquear o acesso de um ou mais profissionais ao invés de liberar o acesso de um ou mais profissionais. Acredito que esse requisito precisa apenas ter a ordem alterada, uma vez que, a funcionalidade permanecerá a mesma. Desta forma, como você mesmo relatou o paciente assina um termo no começo do seu atendimento na instituição e avisa: "não quero ser atendido pela minha ex-mulher", por exemplo.

A preocupação do Luciano sobre S-RES em nuvem e a privacidade das informações realmente é pertinente e atual. 

O requisito NGS1.07.07 na versão 3.3 dizia: 

Os dados de identificação do paciente devem ser criptografados a fim de impedir a reconstrução do seu RES através de acessos não autorizados à base de dados do S-RES ou à cópia de segurança (gerado na salvaguarda dos dados).

Porém foi substituído na versão 4.1 pelo texto:

Impedir a reconstrução do RES por meio de acessos não autorizados à base de dados. 

O texto da versão 3.3 é mais assertivo do que da versão 4.1 porque soluciona o problema da nuvem e acesso da equipe de desenvolvimento, uma vez que, independente de onde os dados estiverem armazenados a identidade do paciente será preservada pela criptografia. E quando falamos de dados de identificação de paciente estamos incluindo o número de registro dele no estabelecimento, CNS, RG, Endereço, ETC...

Luciano, em nossa implementação de SRES em nuvem temos essa preocupação e para que tenha uma ideia da neurose que chegamos estamos criando chaves criptográficas diferentes para ambientes de produção, homologação e desenvolvimento com a finalidade de garantir a privacidade do paciente mesmo junto a nossa equipe de desenvolvimento e suporte. Desta forma, se o canal de comunicação e os dados de identificação do paciente estiverem criptografados a privacidade estarão garantidos.  Agora, isso também tem que ser previsto no manual operacional, porque uma vez que não identifico mais a pessoa aqueles SELECTs na base de dados já não serão possíveis também. Outro ponto que precisa ser abordado com urgência é a construção de aplicativos moveis porque eles também precisam gravar as informações dos pacientes de forma criptografada.

[]'s Flavio Barbosa.

Em segunda-feira, 26 de maio de 2014 09h36min32s UTC-3, Flavio Barbosa (CIAware) escreveu:

Bom dia a todos.

"Todos os dados do RES devem ser segregados por organização, ou seja, nenhum dado do RES de uma organização pode ser acessado ou visualizado por usuário de outra organização."

Todavia, se o paciente foi atendido em um estabelecimento de saúde "A" e ele for ao "B" não poderá solicitar ao S-RES que suas informações fiquem disponíveis na instituição "B"? 

Se sim, isso não vai contra o requisito NGS1.12.07, NGS1.12.06 e NGS1.12.08 que empodera o paciente?

Se não, sugiro acrescentar ao requisito NGS1.07.11 a condição "Salvo, solicitado pelo paciente ou acordado entre as partes.".

[]'s Flavio Barbosa.

--
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br

---
Você recebeu essa mensagem porque está inscrito no grupo quot;Sociedade Brasileira de Informática em Saúde - Lista de Discussão" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para sbis_l+unsubscribe@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br

---
Você recebeu essa mensagem porque está inscrito no grupo quot;Sociedade Brasileira de Informática em Saúde - Lista de Discussão" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para sbis_l+unsubscribe@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.