terça-feira, 30 de dezembro de 2014

Princípios Básicos de Segurança da Informação

Eu lembro que na minha infância costumava se falar muito aquele ditado popular "tempo é dinheiro". Talvez porque naquela época as coisas eram bem mais difíceis... os meios de transportes não eram tão evoluídos (viajar de avião, por exemplo, era uma fortuna), os meios de comunicação idem (telefones fixos custavam o preço de um carro novo e celulares eram aparatos de filmes de ficção científica), então se gastava muito tempo para realizar algumas tarefas que hoje são triviais. A tecnologia encurtou as distâncias e tornou viáveis uma infinidade de novas possibilidades. Hoje mandamos uma mensagem de um lado para o outro do mundo em segundos, quando antes levava meses.
Não obstante, hoje, tempo ainda é dinheiro. Mas talvez mais importante que isso, na era digital, informação é dinheiro. Vivemos num mundo de empresas cada vez mais dependentes de tecnologia, e sobretudo, de seus dados. Devido a toda essa evolução tecnológica encurtando as distâncias, a informação consegue fluir muito rápido e, quando se trata de uma informação crítica para o negócio, é preciso fazer de tudo para que ela não encontre um caminho rápido até as mãos da concorrência.
Na prática, no entanto, vejo muitas empresas não tomarem as devidas precauções com a segurança. O problema, na maioria dos casos, é que uma falha de segurança tem geralmente proporções intangíveis, ou seja, não é possível delimitar um impacto financeiro e nem mesmo dar a certeza de que um dia vai acontecer. Quando se trata de segurança, sempre estamos falando no conceito de risco. Fazer um investimento para mitigar um risco (em contrapartida a uma certeza), não costuma ser muito simples de justificar, exceto quando as companhias já vivenciaram um problema antes.
Outro motivo que tende a minimizar os investimentos em segurança é a própria falta de conhecimento dos profissionais sobre as ferramentas disponíveis no mercado e sobre as regulamentações e normas existentes no setor. O restante deste artigo vou me dedicar a estes dois aspectos.

Regulamentação

As normas que regem o domínio da segurança da informação estão consolidadas na série ISO 27000. Em linhas gerais, a série 27000 especifica a uma estrutura para gerenciamento de segurança da informação para qualquer organização, seja esta pública ou privada, de pequeno ou grande porte.
A ISO/IEC 27000 propriamente dita constitui uma visão geral da família 27000, além de definir um glossário dentro do escopo da Tecnologia da Informação e da gestão da segurança da informação, para melhor entendimento das demais normas que constituem o conjunto.
ISO/IEC 27002:2007 é a norma de Segurança da Informação, que por motivos históricos muitas vezes é referenciada por ISO/IEC 17799:2005, a sua numeração anterior. Ela foi publicada originalmente em 2000, sendo então uma cópia fiel do padrão britânico (BS 7799-1:1999), e passou por uma revisão em 2005 para se adaptar ao mercado internacional.

Objetivos de Segurança

A segurança da informação estabelece alguns princípios básicos que precisam ser “forçados” para garantir a proteção dos dados. Estes princípios, também conhecidos como atributos, objetivos ou propriedades (entre outros), regem o foco das políticas de segurança e as funcionalidades que as ferramentas de tecnologia dispõe para controla-los.
O coração da segurança da informação costuma ser definido pela tríade clássica: confidencialidade, integridade e disponibilidade. A medida que o estudo desta área foi evoluindo, diversos autores e comitês propuseram princípios adicionais. A ISO/IEC 27002:2007 define, além da tríade clássica, os princípios da autenticidade e da irretratabilidade (ou não repúdio). Resumidamente, os 5 princípios regem sobre os seguintes aspectos:
  • Confidencialidade: o acesso a informação deve ser permitido apenas as entidades autorizadas.
  • Integridade: a informação deve ser preservada da forma como o seu proprietário a definiu e/ou modificou, durante todo o seu ciclo de vida, sendo protegida contra modificações não autorizadas ou não detectadas.
  • Disponibilidade: a informação deve estar acessível aos usuários autorizados ao seu acesso sempre que necessário.
  • Autenticidade: garantia de que a informação é genuína e que os sujeitos autorizados que a modificaram, ao longo do seu ciclo de vida, são realmente quem dizem ser (e não um terceiro impersonando um sujeito autorizado).
  • Irretratabilidade (não-repúdio): é a impossibilidade de negar a autoria de uma transação realizada anteriormente sobre um determinado conjunto de dados

Políticas de Segurança

Para cumprir com os objetivos de segurança é necessário ter uma política de segurança bem definida. Conforme a RFC 2196 – Site Security Handbook – uma política de segurança é uma declaração formal das regras as quais as pessoas que possuem acesso a informações e tecnologia de uma organização devem respeitar. O principal propósito de uma política de segurança é informar aos usuários, equipe e gerentes de suas obrigações para proteger os bens da companhia, sejam estes bens informações ou tecnologia.
A política deve especificar os mecanismos pelos quais estes requisitos são cumpridos. Para que a política seja eficiente, todos os procedimentos precisam ser documentados e estarem prontamente disponíveis a todos os atores, cada qual com o seu papel muito bem definido. Além disso, ferramentas precisam ser implementadas para garantir as regras e sansões precisam ser definidas onde as ferramentas não conseguem proteger o bem automaticamente.
Note que, neste processo, grande ênfase é dada ao papel das pessoas. Em contrapartida, as ferramentas têm um papel importante, porém não tem valor se não forem operadas e implementadas corretamente. Nada vale um sistema de segurança em uma empresa onde, por exemplo, para não esquecer a senha o funcionário deixa um post-it com suas senhas coladas no monitor. Sim, isso acontece.
Mas de qualquer forma, as ferramentas de tecnologia desempenham um papel fundamental no controle da informação e na garantia de que as propriedades básicas sejam asseguradas. Sem a tecnologia apropriada, hoje, é impossível manter o controle do volume de informações que transitam entre os mais diversos sistemas que compõem a infraestrutura das empresas.

Tipos de Controles na Tecnologia de Informação

Nos voltando agora para a tecnologia da informação, podemos classificar os mecanismos que temos para atuar sobre a segurança da informação em dois níveis básicos de controle: o controle preventivo, ou seja, os mecanismos que temos para prevenir que uma ação mal intencionada seja efetuada e, o controle reativo, aquele que nos permite agir mediante uma falha de segurança.
Quando entramos a fundo nas regulamentações de mercado no que tange a tecnologia, é comum encontrarmos a divisão do controle da TI em dois domínios: o domínio das aplicações e o domínio geral, que seria correspondente ao domínio da infraestrutura.
O domínio das aplicações é regido pelo acesso dos usuários aos aplicativos corporativos. Geralmente as próprias aplicações possuem algum tipo de controle para que apenas usuários autorizados tenham acesso às informações, porém algumas ferramentas específicas de TI tendem a melhorar este controle fornecendo algumas facilidades, como por exemplo, o Single Sign-On (SSO) ou outras modalidades de gerenciamento de acesso e controle de chaves.
Logo, no domínio das aplicações consideramos um risco o acesso de pessoas não autorizadas pela própria camada de aplicação, seja pela incorporação de uma identidade (ex.: roubo de senha, personificação ou fraude) ou por uma falha no controle de acesso (ex.: um funcionário demitido com credenciais ainda válidas).
No domínio geral, ou infraestrutura, os pontos de risco são mais amplos. Pensando em segurança da informação, o objeto mais crítico é o banco de dados, onde todas as informações das aplicações estão armazenadas. Como pontos chave para falhas de segurança temos desde a comunicação entre os servidores de banco de dados e de aplicação (camada de rede), o acesso direto aos dados (via sistema operacional), o acesso irrestrito de usuários privilegiados e, finalmente, a exposição indevida de dados críticos a desenvolvedores de sistema.
Permitam-me elaborar um pouco sobre cada um deles, e as maneiras de proteger-se contra cada um destes riscos:
1) Comunicação entre aplicação e banco de dados: toda e qualquer comunicação entre computadores está sujeita ao que chamamos de “sniffing” ou “packet capture”, entre outros termos, que nada mais é a interceptação das informações transmitidas de ponto a ponto por um software terceiro. Uma forma de se proteger deste tipo de ataque é através da criptografia, pois assim mascaramos os dados transmitidos de uma ponta a outra e sem a chave o terceiro não consegue decodificar a mensagem.
2) Acesso direto aos dados: semelhante ao item anterior, se os dados são armazenados “planos” (sem criptografia), não importa quantas camadas de segurança e autenticação você coloque, uma pessoa com acesso a uma cópia do banco de dados pode acessar todas as informações contidas nele com um grau moderado a leve de dificuldade. Imagine o cenário onde, por exemplo, que o “motoboy” que vai levar as fitas de backup para o cofre perde uma destas fitas ou é roubado. Ou um sysadmin mal-intencionado faz uma cópia dos datafiles do banco. A criptografia também é a solução para estes problemas.
3) Acesso irrestrito de usuários privilegiados: administradores de banco de dados (DBAs) geralmente são profissionais com o mais alto nível de acesso em uma infraestrutura de banco de dados. Isto se deve a própria característica do trabalho, pois, eles devem ter o poder tanto de criar como, literalmente, destruir o banco. Mas deveriam eles ter acesso às informações contidas no banco? Não necessariamente. Por exemplo, um DBA não deveria ter acesso a uma tabela de salários em um sistema de RH. Na prática, muitos têm. A forma de controlar isso depende muito de banco para banco.
4) Exposição de dados críticos a desenvolvedores de sistemas: também de nada adianta tomar todas as precauções com a segurança - criptografia, controle de acesso e limitação de usuários privilegiados - se deixamos os dados de produção completamente expostos no ambiente de desenvolvimento. É muito comum criarmos massas de dado para desenvolvimento e testes a partir dos dados de produção, mas nestes ambientes secundários os mecanismos de segurança são mais relaxados ou inexistentes. Em decorrência disso, qualquer desenvolvedor com acesso direto ao banco pode ter acesso a dados que jamais deveria ter conhecimento. Aí mais uma vez para ilustrar uso o exemplo do sistema de RH, onde o salário de todos os funcionários está exposto. Mas não só isso, poderiam ser informações estratégicas de negócio da própria empresa ou de uma empresa cliente. Um risco este que pode ser mitigado através da estratégia de mascaramento de dados, descaracterizando os dados sensíveis de maneira irreversível, mas mantendo suas características relacionais para que testes permaneçam válidos.

A tecnologia Oracle voltada para a segurança

Como especialista em Oracle eu não poderia deixar de indicar as tecnologias que a Oracle tem para endereçar cada uma destas necessidades.
Para trabalhar com controle no domínio das aplicações, a Oracle dispõe da suíte deIdentity Management (IDM). Esta é uma suíte completa que inclui produtos para controle de acesso, gestão de identidade, single sign-on, governança, serviços de diretório, mobile e etc.
Já para trabalhar no domínio geral, a Oracle conta com algumas opções de banco para atuar tanto no controle preventivo como reativo. De modo geral estes produtos são comercializados como options do banco Oracle Database Enterprise Edition (DBEE) ou como packs para o Enterprise Manager. Alguns destes produtos, no entanto, podem ser utilizados em conjunto com outros bancos de dados que não são Oracle.
Para trabalhar com criptografia de banco de dados (data files e backup), a ferramenta é chamada de Transparent Data Encryption (TDE), sendo comercializada como option do Oracle Database Enterprise Edition com o nome de Advanced Security. Para criptografia de rede, entre banco de dados e aplicação, até junho de 2013 este recurso também fazia parte da option Advanced Security, porém desde então agora ela faz parte da funcionalidade padrão do banco de dados Oracle Database Enterprise Edition.
O controle de usuários privilegiados, considerando o banco de dados Oracle Enterprise Edition, pode ser feito através da option Database Vault. O objetivo desta option é assegurar que os usuários privilegiados (DBAs e SYSDBAs) continuem com os seus “super poderes” administrativos, porém não tenham acesso a dados sensíveis.
Finalmente, para trabalhar com o mascaramento dos dados de produção na hora de replicar o ambiente para desenvolvimento, a ferramenta da Oracle é um pack do Enterprise Manager 12c chamado de Data Masking and Subsetting. Este pack é capaz não só de descaracterizar os dados como também exportar apenas um subconjunto dos dados de produção mantendo sua integridade referencial, mas reduzindo os requisitos de espaço na base de dados de desenvolvimento. Um fato interessante é que esta ferramenta é multi-banco, ou seja, não funciona apenas em bancos de dados Oracle.
Todas as ferramentas acima trabalham no conceito de controle preventivo. Para fechar o raciocínio dos tipos de controle e suas soluções faltou comentar sobre o controle reativo. A ferramenta que dispomos para tratar este tipo de controle é chamada de Audit Vault, um repositório de informações de auditoria isolado dos ambientes que monitora e totalmente desenvolvido com as melhores práticas de segurança para que não haja alteração dos dados auditados. O princípio é que, no advento de uma falha de segurança, hajam informações disponíveis para rastrear a origem da falha e punir com as devidas sanções os responsáveis. O Audit Vault, assim como o Data Masking, é uma ferramenta que pode ser usada também em bancos não-Oracle, incluindo SQL Server, DB2 e outros.

Palavras Finais

Espero com este artigo ter conseguido mostrar um pouco do mundo da segurança da informação e as possíveis vulnerabilidades as quais as empresas estão sujeitas no dia a dia. Como minha especialidade é Oracle, tomei a liberdade também de mostrar algumas das ferramentas dentro do nosso portfólio podem ser utilizadas para atacar os pontos de risco citados no artigo. De maneira alguma o meu objetivo foi ser exaustivo na descrição destas ferramentas, mas sim dar uma visão geral do que está disponível no mercado.
Caso haja mais interesse em conhecer o portfólio de segurança da Oracle, fiquem a vontade para entrar em contato. Estarei a disposição para esclarecer quaisquer dúvidas que por ventura possam aparecer.
E para finalizar, vale lembrar aquilo que eu comentei anteriormente sobre política de segurança e ferramentas. De nada adianta investir em ferramentas top de linha se não houver uma mudança de cultura corporativa, afinal segurança é um conceito extremamente dependente das pessoas. Para que uma política de segurança funcione corretamente, não basta ter as ferramentas corretas, mas também é preciso treinar as pessoas e deixar muito claro através de políticas, papéis e sanções o que cabe a cada um fazer.

Nenhum comentário:

Postar um comentário