IBM Cloud Docs
Orientação sobre as operações

Orientação sobre as operações

Esta seção fornece orientação sobre a execução do MS SQL no IBM Cloud VPC antes e depois da implementação inicial dos padrões de implementação do Microsoft SQL.

Para obter mais informações, consulte Entenda suas responsabilidades ao usar o Virtual Private Cloud.

Identity and Access Management

A Gerência de Identidade e Acesso (IAM) possibilita o controle de recursos em sua conta IBM Cloud . Os recursos são organizados em grupos de recursos e dão acesso a usuários de conta e IDs de serviço via políticas de acesso IAM. A adoção do princípio da separação de deveres garante que seus usuários do IBM Cloud e IDs de serviço tenham apenas o acesso necessário para desempenhar suas funções. Consulte o seguinte para obter um entendimento inicial do IBM Cloud IAM e para configurar sua conta IBM Cloud para ativar a segregação de tarefas.

Activity Tracker

IBM Cloud Activity Tracker registra atividades que alteram o estado de um serviço em IBM Cloud através do UI/CLI / API. Você pode usar o serviço Activity Tracker para investigar atividades anormais e ações críticas e para cumprir os requisitos de auditoria regulatória. Além disso, você pode ser alertado sobre ações como elas ocorrem. Os eventos que são coletados obedecem ao padrão Cloud Auditing Data Federation (CADF). Consulte o Activity Tracker para obter informações sobre quais eventos são rastreados em VPC e Introdução ao Activity Tracker.

Logs de fluxo

IBM Cloud Flow Logs for Virtual Private Cloud (VPC) habilitam a coleta, o armazenamento e a apresentação de informações sobre o tráfego de Internet Protocol (IP) indo e a partir de interfaces de rede dentro do seu VPC. Os logs de fluxo podem ajudar com várias tarefas, incluindo a resolução de problemas por que o tráfego específico não está atingindo uma instância de servidor virtual para diagnosticar as regras do grupo de segurança, bem como possibilitar a adesão aos regulamentos de conformidade. consulte Sobre Flow Logs para obter mais informações.

Um log de fluxo é um resumo do tráfego de rede entre duas placas de interface de rede virtual (vNICs), dentro de um espaço de tempo. Um log de fluxo descreve o tráfego que grupos de segurança ou ACLs de rede aceita ou rejeita. Um log de fluxo contém informações de cabeçalho e estatísticas de carga útil para tráfego Transmission Control Protocol (TCP) e UDP (User Datagram Protocol), mas não tráfego de Internet Control Message Protocol (ICMP). Os componentes principais são os seguintes:

  • Coleção-Os coletores de log do Flow são configurados para coletar dados de fluxo e os coletores podem ser configurados com diferentes escopos:
    • VPC-Coleta dados para todas as interfaces de rede em um VPC específico.
    • Subnet-Coleta dados para todas as interfaces de rede em uma sub-rede específica.
    • Instância-Coleta dados para todas as interfaces de rede em um servidor virtual específico.
    • Interface-Coleta dados para uma interface de rede específica em um servidor virtual específico.
  • Armazenamento-Os logs do Flow são armazenados em um balde IBM Cloud Object Storage (COS). Este balde é configurado durante a configuração do coletor de log de fluxo.
  • Apresentação- IBM Cloud SQL Query é o serviço de SQL sem servidor da IBMem dados sobre COS, e é usado para criar consultas nos logs de fluxo armazenados na COS. Consulte Viewing flow log objects e Usando IBM Cloud SQL Query para obter mais informações.

Monitoramento

IBM Cloud Monitoring é um sistema de monitoramento nativo em nuvem que você pode incluir como parte da sua arquitetura IBM Cloud , para ganhar visibilidade operacional no desempenho e na saúde de seus servidores. Depois de uma instância do serviço IBM Cloud Monitoring ter sido provisionada, um agente de monitoramento é instalado em cada host que você deseja monitorar. Através da UI web você é capaz de monitorar seus recursos, configurar alertas e explorar eventos.

Para monitorar um sistema Windows com o IBM Cloud Monitoring, o Prometheus WMI Expoter é usado para realizar a coleta das métricas no sistema. Há duas opções para publicação das métricas:

  1. Execute um agente de monitoramento em um sistema Linux e extraia remotamente o terminal do Windows.
  2. Use os recursos de gravação remota do Prometheus para enviar por push as métricas do sistema Windows executando o Prometheus como um coletor de clientes no Windows.

Para ver a etapa por instalação de etapa e configuração consulte Monitorando um ambiente Windows.

Análise de logs

O serviço IBM Log Analysis possibilita o gerenciamento de logs de eventos a partir de recursos em IBM Cloud. IBM Log Analysis oferece recursos para filtrar, pesquisar, definir alertas e projetar visualizações personalizadas para monitorar logs. Consulte a Visão Geral para uma visão geral do serviço. Log Analysis não suporta nativamente o registro de logs do Windows. Por isso, um serviço de registro centralizado alternativo precisará ser utilizado.

Backup

O backup e a restauração no SQL Server podem ser categorizados como integração nativa ou de terceiros:

  • Nativo-Para mais informações, consulte Quickstart: Backup e restore um banco de dados SQL Server que descreve o processo de criação de um backup de banco de dados completo e restauração de um backup usando o SQL Server Management Studio (SSMS). O backup é armazenado no local de backup configurado durante a instalação do SQL Server ou de um local definido pelo usuário, como um compartilhamento de arquivos. Os backups podem ser planejados usando um job do Agente SQL Server . Para uma descrição completa dos conceitos do SQL Server , consulte Visão Geral do Backup (SQL Server).
  • Integração de terceiros-Há uma série de integrações de terceiros disponíveis e aqui descrevemos apenas três; IBM Spectrum Protect, Veeam e IBM Spectrum Protect Plus:
    • IBM Spectrum Protect -Proteção de dados para SQL permite realizar backups online e restaurações de bancos de dados Microsoft SQL Server para um IBM Spectrum Protect Storage Manager Server. Para uma descrição de implementar o IBM Spectrum Protect Storage Manager Server, consulte IBM Spectrum Protect Cloud Blueprints. A instalação de Data Protection para SQL é coberta em Download Information: Version 8.1.9 IBM Spectrum Protect for Databases.
    • Veeam-Veeam Agent for Microsoft Windows é uma solução de proteção de dados e disaster recovery que pode ser implementada em instâncias do servidor virtual do IBM Cloud VPC . Para obter mais informações, consulte Usando Agente Veeam. Também é possível utilizar o Veeam Agent para o Microsoft Windows com o Veeam Backup e o Replicação, onde o Veeam Backup e o Replicação fornece uma solução de backup centralizada para todos os seus Agentes Veaam. Para obter mais informações, consulte Usando o software Veeam Backup e Replicação. Para obter mais informações sobre o backup do SQL Server, veja Back Up Microsoft SQL Server
    • IBM Spectrum Protect Plus - IBM Spectrum Protect Plus é uma solução de proteção de dados para ambientes virtuais, vSphere ou Hyper-V, e fornece proteção de dados de aplicativos para muitos aplicativos, incluído SQL Server, hospedado no IBM Cloud VPC servidores virtuais. IBM Spectrum Protect Plus pode ser implementado como uma solução independente ou pode se integrar com o seu ambiente IBM Spectrum Protect para transferir cópias para armazenamento e governança de longo prazo. IBM Spectrum Protect Plus pode ser instalado automaticamente em IBM Cloud para um ambiente existente do VMware , veja Spectrum Protect Plus Server para obter mais informações. Para obter informações específicas sobre IBM Spectrum Protect Plus e SQL Server, veja Backing up e restauração de dados SQL Server.

IBM Cloud Security and Compliance Center

IBM Cloud Security and Compliance Center possibilita a identificação de vulnerabilidades de segurança para que você possa trabalhar para mitigar o impacto e corrigir a questão da vulnerabilidade. Um perfil Red Hat Enterprise Linux, CentOSou servidor virtual Ubuntu cx2-2x4 (2 vCPUs, 4 GB RAM e 4Gbps) é necessário para ser implementado no VPC para atuar como host coletor. Um coletor é um módulo de software que é empacotado como uma imagem do Docker.

Um perfil é uma coleção de metas relacionadas, ou verificações de segurança, usadas para validar seus recursos contra os regulamentos internos e externos. Consulte a Postura de segurança e conformidade com o VPC

Um escopo é usado para estreitar o foco de uma varredura para um ambiente, região ou recurso específico. Uma varredura é então programada para descobrir recursos, avaliar sua configuração e validar sua conformidade contra um perfil predefinido. Consulte a Introdução ao Security and Compliance Center

Criptografia de dados

Os volumes de inicialização primária e os volumes de dados secundários são criptografados automaticamente usando a criptografia gerenciada pela IBM, no entanto, você também pode optar por gerenciar sua própria criptografia usando a criptografia gerenciada pelo cliente. Os serviços de gerenciamento de chaves suportados são Key Protect e Hyper Protect Crypto Services (HPCS). Para obter mais informações, consulte Sobre a criptografia de dados para VPC.

Grupos de Segurança

IBM Cloud Security Groups para VPC permitem que regras sejam aplicadas que permitem a filtragem a cada interface de rede de uma instância do servidor virtual, com base em seu endereço IP.

  • Por padrão, um grupo de segurança nega todo o tráfego.
  • Conforme regras são adicionadas ele define o tráfego permitido.
  • As regras são stateful, portanto, o tráfego reverso em resposta ao tráfego permitido é automaticamente permitido.
  • Os grupos de segurança têm o escopo definido para uma única VPC.
  • Se você tiver vários servidores virtuais em um grupo de segurança, o tráfego entre servidores ainda precisa ser permitido.

Para obter mais informações, consulte Sobre grupos de segurança.

Listas de controle de acesso

As Listas de Controle de Acesso (ACL) controlam todo o tráfego de entrada e saída para e a partir de sub-redes VPC, em vez de um grupo de segurança que controla o tráfego para e a partir de instâncias do servidor virtual.

  • Uma ACL é stateless, portanto, ambas as regras de entrada e saída devem ser especificadas separadamente e explicitamente.
  • Cada ACL consiste em regras, com base em um IP de origem, porta de origem, IP de destino, porta de destino e protocolo.
  • Uma sub-rede pode ter apenas uma ACL conectada a ela a qualquer momento, mas uma ACL pode ser conectada a várias sub-redes.
  • As regras são processadas em sequência.
  • Cada VPC tem uma ACL padrão que permite todo o tráfego de entrada e saída.

Como proteger o Microsoft Windows Server

Centro de benchmarks de Segurança da Internet (CIS) são linhas de base de configuração e melhores práticas para configurar de forma segura um sistema e referências um ou mais controles do CIS . CIS controla mapa para muitos padrões estabelecidos e frameworks regulatórios, incluindo o NIST Cybersecurity Framework (CSF) e NIST SP 800-53, a série ISO 27000 de padrões, PCI DSS, HIPAA e outros. Consulte Securing Microsoft Windows Server para obter informações sobre o hardening the Windows OS e Securing Microsoft SQL Server para obter informações sobre o endureamento do MS SQL 2019.

Patching do servidor Windows

Não há servidores de atualização da Microsoft na rede do IBM Cloud VPC , portanto, é necessário o acesso aos repositórios da Microsoft via Internet. Isso pode ser alcançado por:

Você precisará atualizar grupos de segurança e ou listas de controle de acesso para permitir esse tráfego de atualização.

Patching do servidor SQL

Microsoft libera pacotes Cumulativos (CU) para servidor SQL a cada 2 meses. Cada CU contém o pacote acumulado anterior. Para o SQL Server 2019 os CUs podem ser acessados em atualizações mais recentes para o Microsoft SQL Server. Adicionalmente consulte as versões de construção do SQL Server 2019.

A seguir, um resumo curto do processo de correção em um grupo Always On availability:

  • Preparação:
    • Determine o nível de correção atual.
    • Defina o nível de correção de destino i.e N ou N-1.
    • Leia as notas de liberação de correção.
    • A melhor prática é testar o patch em um ambiente de teste antes de patinhar um ambiente de produção.
    • Verifique se você tem os backups mais recentes para os bancos de dados do sistema e bancos de dados do usuário na réplica primária. O ideal você terá backups completos; no entanto, para bancos de dados muito grandes, um backup diferencial ou o backup de log da transação deve estar disponível
    • Nas réplicas secundárias, tenha o backup de banco de dados do sistema mais recente disponível.
    • Verifique o funcionamento do grupo de disponibilidade utilizando o painel de disponibilidade no SQL Server Management Studio. Os bancos de dados do grupo de disponibilidade devem estar no estado Synchronized para o estado síncrono e o estado Synchronizing para o modo de confirmação assíncrono.
  • Patching:
    • Aplique a correção na réplica secundária no MZR primário ou seja, o servidor SQL em AZ2, se aplicável:
      • Usando o SSMS, altere o modo de failover de Automatic para Manual para garantir que nenhum failover automático aconteça enquanto as correções são instaladas.
      • Usando o SSMS, suspenda o movimento de dados para os bancos de dados de réplica secundária para que a réplica primária não envie nenhum bloco de transação para a réplica secundária específica.
      • Via RDP para o servidor hospedando a réplica secundária, aplique o CU.
      • Reinicie o servidor .
      • Uma vez que a réplica secundária vem online, conecte-se a ele usando SSMS e realize a seguinte validação:
        • Verificar os Serviços SQL estão online.
        • Validação da versão do SQL Server .
        • Revise os logs de erros do SQL Server para quaisquer erros, avisos.
        • Recomenda-se também realizar um verificador de consistência de banco de dados (DBCC CHECKDB) após a aplicação dos patches.
        • Usando SSMS, retome o movimento de dados para o banco de dados de réplicas secundárias e aguarde o painel do grupo de disponibilidade mostrar-se saudável.
    • Aplique a correção na réplica secundária no MZR de recuperação, se aplicável:
      • Usando o SSMS, suspenda o movimento de dados para os bancos de dados de réplica secundária para que a réplica primária não envie nenhum bloco de transação para a réplica secundária específica.
      • Via RDP para o servidor hospedando a réplica secundária, aplique o CU.
      • Reinicie o servidor .
      • Uma vez que a réplica secundária vem online, conecte-se a ele usando SSMS e realize a seguinte validação:
      • Verificar os Serviços SQL estão online.
      • Validação da versão do SQL Server .
      • Revise os logs de erros do SQL Server para quaisquer erros, avisos.
      • Recomenda-se também realizar um verificador de consistência de banco de dados (DBCC CHECKDB) após a aplicação dos patches.
      • Usando SSMS, retome o movimento de dados para o banco de dados de réplicas secundárias e aguarde o painel do grupo de disponibilidade mostrar-se saudável.
    • Aplique a correção na réplica primária:
      • Usando SSMS, execute um failover manual da réplica primária para a réplica secundária no MZR primário. Após o failover, a réplica primária muda seu estado para uma réplica secundária.
      • Usando o SSMS, suspenda o movimento de dados para os bancos de dados de réplica secundária para que a réplica primária não envie nenhum bloco de transação para a réplica secundária específica.
      • Via RDP para o servidor hospedando a réplica secundária, aplique o CU.
      • Reinicie o servidor .
      • Uma vez que a réplica secundária vem online, conecte-se a ele usando SSMS e realize a seguinte validação:
        • Verificar os Serviços SQL estão online.
        • Validação da versão do SQL Server .
        • Revise os logs de erros do SQL Server para quaisquer erros, avisos.
        • Recomenda-se também realizar um verificador de consistência de banco de dados (DBCC CHECKDB) após a aplicação dos patches.
        • Usando SSMS, execute um failback de disponibilidade. Após o failover, a réplica primária do grupo de disponibilidade é o nó primário.
        • Altere o modo de failover para automático para as réplicas primárias e secundárias configuradas com o modo de confirmação de dados síncrono.
  • Pós-patching:
    • Usando SSMS, execute um failover de grupo de disponibilidade e failback e valide que o painel de disponibilidade do SSMS é saudável.
    • Revise os logs de erros em todas as réplicas.
    • Validar o acesso à aplicação