Go to main content

Guia de Segurança do Oracle SuperCluster Série M7

Sair da Exibição de Impressão

Atualizado: Fevereiro de 2016
 
 

Controle de Acesso

Para organizações que adotaram uma estratégia de ambiente hospedado na nuvem, o controle de acesso é um dos desafios mais críticos a serem resolvidos. Os tenants devem ter certeza de que as informações armazenadas na estrutura compartilhada estão protegidas e disponíveis apenas para hosts, serviços, indivíduos, grupos e funções autorizados. Hosts, indivíduos e serviços autorizados devem ser ainda mais limitados, de acordo com o princípio de menor privilégio, de forma que eles tenham apenas os direitos e privilégios necessários para uma operação específica.

O SuperCluster facilita uma arquitetura de controle de acesso em camadas flexível que abrange cada camada da pilha e dá suporte a uma variedade de funções incluindo usuários finais, administradores de banco de dados e administradores de sistemas. Isso permite às organizações definir políticas que protejam hosts, aplicativos e bancos de dados individualmente e proteger a infraestrutura de computação, armazenamento e rede subjacente na qual os serviços são executados.

Nas camadas de virtualização e sistema operacional, o controle de acesso começa com a redução do número de serviços expostos na rede. Isso ajuda a controlar o acesso aos consoles do Oracle VM Server para SPARC, domínios e zonas. Ao reduzir o número de pontos de entrada pelos quais os sistemas podem ser acessados, o número de políticas de controle de acesso também pode ser reduzido e mantido com mais facilidade durante a vida do sistema.

No Oracle Solaris OS, os controles de acesso são implementados usando uma combinação de permissões POSIX juntamente com o recurso de controle de acesso baseado em funções (RBAC) do Oracle Solaris. Igualmente importante é a capacidade de proteger os hosts, aplicativos, bancos de dados e serviços relacionados em execução no SuperCluster contra ataques baseados na rede. Para fazer isso, os tenants devem primeiro verificar se apenas serviços de rede aprovados estão em execução e ouvindo conexões de rede de entrada. Uma vez minimizada a superfície de ataques da rede, os tenants, em seguida, configuram os serviços restantes de modo que eles escutem conexões de entrada somente em redes e interfaces aprovadas. Essa prática simples ajudará a garantir que os protocolos de gerenciamento, como o Secure Shell, não sejam acessíveis de nenhum local além da rede de gerenciamento.

Figura 6  Resumo do Controle de Acesso de Ponta a Ponta

image:Ilustração mostrando os recursos de segurança de chaves para componentes de banco de dados, rede, armazenamento e computação.

Além disso, os tenants também podem optar por implementar um firewall baseado em host, como o serviço IP Filter do Oracle Solaris. Os firewalls baseados em host são úteis porque fornecem aos hosts uma forma mais rica em recursos de controlar o acesso a serviços de rede. Por exemplo, recurso Filtro de IP dá suporte à filtragem de pacotes com monitoração de estado e pode filtrar pacotes pelo endereço IP, porta, protocolo, interface de rede e direção do tráfego. Esses recursos são importantes para plataformas, como SuperCluster, que operam muitas interfaces de rede e dão suporte a uma variedade de comunicações de rede de entrada e saída.

No SuperCluster, o Filtro de IP pode ser configurado em um domínio do Oracle VM Server para SPARC ou operado de dentro de uma Zona do Oracle Solaris. Isso permite que a política de controle de acesso seja aplicada no mesmo contêiner de sistema operacional no qual os serviços de banco de dados são oferecidos. Em um cenário multitenant, a quantidade de atividades de rede de saída provavelmente será mínima e poderá facilmente ser categorizada de forma que seja possível criar uma política que limite as comunicações a interfaces de rede e destinos específicos. Todo o restante do tráfego seria negado e registrado como parte de uma política "de negação padrão" para bloquear comunicações não autorizadas, tanto de entrada quanto de saída.

A segurança de usuários finais da Oracle permite aos tenants integrar seus aplicativos e bancos de dados com seus serviços de gerenciamento de identidades existente a fim de dar suporte ao single sign-on (SSO) e ao gerenciamento centralizado de usuários e funções. Especificamente, a Segurança de Usuários Finais da Oracle ajuda a centralizar (1) o provisionamento e o desprovisionamento de usuários e administradores de banco de dados, (2) o gerenciamento e a redefinição de senhas de autoatendimento e (3) o gerenciamento de autorizações usando funções globais de banco de dados. As organizações que precisam de métodos de autenticação multifator, como Kerberos ou PKI, podem tirar proveito da Segurança Avançada da Oracle.

A tecnologia do Oracle Exadata Storage Server dá suporte a um conjunto predefinido de contas de usuário, cada uma com privilégios distintos. Os administradores que realizam a administração do Oracle Exadata Storage Server devem usar uma destas funções predefinidas para acessar o sistema. Por outro lado, o appliance de armazenamento de ZFS dá suporte à criação de contas administrativas locais e remotas, que podem dar suporte à atribuição individual de funções e privilégios.

Por padrão, os Servidores de Armazenamento Oracle Exadata usados no SuperCluster são acessados pelos domínios de banco de dados usando o recurso Oracle Automatic Storage Management. Esse recurso permite aos provedores de nuvem criar grupos de discos distintos para cada tenant que sejam capazes de atender aos seus requisitos de capacidade, desempenho e disponibilidade. Em termos de controle de acesso, o Oracle Automatic Storage Management dá suporte a três modos de controle de acesso: segurança aberta, segurança no escopo do Oracle Automatic Storage Management e segurança no escopo do banco de dados.

Em um cenário multitenant, a segurança no escopo do banco de dados é recomendada porque oferece o nível mais refinado de controle de acesso. Nesse modo, é possível configurar grupos de discos de forma que eles só possam ser acessados por um banco de dados. Especificamente, isso significa que é possível limitar o acesso dos administradores de banco de dados e dos usuários apenas aos discos de grade que contêm informações para as quais eles tenham privilégios de acesso. Em cenários de consolidação de banco de dados nos quais bancos individuais podem dar suporte a diferentes organizações ou tenants, é importante que cada tenant possa acessar e manipular somente seu próprio armazenamento. Especificamente, quando combinado com as estratégias de isolamento de bancos de dados e cargas de trabalho discutidas anteriormente, os tenants podem efetivamente compartimentar o acesso a bancos de dados individuais.

A segurança no escopo do banco de dados é uma ferramenta eficaz para limitar o acesso a discos de grade do Oracle ASM. Esta figura mostra a segurança no escopo do Oracle ASM juntamente com a segurança de ZFS. Em situações nas quais há grandes quantidades de instâncias do Oracle Database sendo implantadas na plataforma do SuperCluster, uma estratégia no escopo do Oracle ASM por tenant pode fazer mais sentido porque ela reduz significativamente o número de chaves que precisam ser criadas, atribuídas e gerenciadas. Além disso, como a segurança no escopo do banco de dados exige que grupos de discos separados sejam criados para cada banco de dados, essa abordagem também reduzirá significativamente o número de discos de grade separados que precisam ser criados em um Exadata Storage Server.

Figura 7  Segurança no Escopo do Oracle ASM por Tenant

image:Figura mostrando a segurança no escopo do Oracle ASM por tenant.

O SuperCluster tira proveito da proteção de link de dados do Oracle Solaris, que procura impedir possíveis danos que possam ser causados por máquinas virtuais de tenant mal-intencionadas na rede. Esse recurso integrado do Oracle Solaris oferece proteção contra as seguintes ameaças básicas: falsificação de endereços IP e MAC, bem como falsificação de quadros L2 (por exemplo, ataques de Bridge Protocol Data Unit). A proteção de link de dados do Oracle Solaris também pode ser aplicada individualmente a todas as zonas não globais do Oracle Solaris implantadas no ambiente multitenant.

Como os tenants individuais nunca devem exigir acesso no nível do host ou administrativo aos Exadata Storage Servers, é altamente recomendável que esse acesso seja restrito. Os Exadata Storage Servers devem ser configurados para impedir o acesso direto para zonas não globais de tenant e domínios de E/S de banco de dados permitindo, ao mesmo tempo, o acesso a partir dos domínios de banco de dados do SuperCluster (que são operados pelo provedor de nuvem). Isso garante que os Exadata Storage Servers possam ser gerenciados apenas de locais confiáveis na rede de gerenciamento.

Uma vez definida e implementada a configuração de segurança dos tenants, os provedores de serviços podem considerar a etapa adicional de configurar zonas não globais e globais específicas de tenants como ambientes imutáveis, de somente leitura. As zonas imutáveis criam um ambiente operacional resiliente de alta integridade no qual os tenants podem operar seus próprios serviços. Com base nos recursos de segurança inerentes do Oracle Solaris, as zonas imutáveis garantem que alguns (ou todos) os diretórios e arquivos do SO não possam ser alterados sem a intervenção do provedor de serviços em nuvem. A aplicação dessa postura somente leitura ajuda a prevenir alterações não autorizadas, promove procedimentos de gerenciamento de alterações mais fortes e impedem a injeção de malware baseado em kernel e baseado em usuário.