Configurar Instâncias Oracle com Linux HugePages

Os Sistemas Operacionais Linux possuem uma funcionalidade muito interessante chamada de HugePages, que quando usada por um banco Oracle oferece grandes ganhos de performance.

HugePages consiste em tornar os blocos de alocação de memória muito maiores do que os 4KB padrão. No Linux os HugePages possuem 2MB por padrão. Outra vantagem é que os HugePages são sempre alocados na memória física e nunca vão para a área de swap. Na verdade esses blocos de memória sequer são considerados como candidatos a ir para swap.

Configuração

A primeira coisa a ser feita para a configuração é identificar quanta quantidade de memória você necessita para ser usada como HugePages. No caso de uma instância Oracle você deve alocar uma quantidade de memória suficiente para acomodar todo o seu SGA. Para isso use a fórmula abaixo.

X = Y / Z

Onde:

X: Quantidade de HugePages necessárias
Y: Tamanho do seu SGA também em KB
Z: Tamanho do HugePage em KB

Obs.: Uma dica é sempre configurar um valor um pouco maior do informado na fórmula. Eu normalmente somo 8 no resultado encontrado.

Agora que você já sabe o número de HugePages que deve configurar, vamos colocar a mão na massa!

Configurando o Linux

O primeiro passo é editar o arquivo /etc/sysctl.conf e adicionar os seguintes parâmetros:

vm.nr_hugepages=<Número de HugePages>
vm.hugetlb_shm_group=<ID do grupo principal do usuário oracle>

Para verificar o ID do grupo principal (gid) do usuário oracle utilize o comando id:

# id oracle
uid=500(oracle) gid=501(oinstall) groups=501(oinstall),500(dba)

No exemplo acima o ID é 501.

O passo seguinte é editar o arquivo /etc/security/limits.conf e definir a quantidade máxima de memória que o usuário oracle pode alocar:

oracle     soft    memlock  8404992 oracle     hard    memlock  8404992

O valor deve ser informado em KB e ser maior que o SGA.

Depois de configurar esses parâmetros reinicie o S.O. para que as configurações entrem em vigor. Para validar use os seguintes comandos:

# cat /proc/meminfo
MemTotal:       264234552 kB
MemFree:        10208592 kB
Buffers:          924660 kB
Cached:         103365808 kB
SwapCached:        74752 kB
Active:         61245124 kB
Inactive:       66576684 kB
Active(anon):   56581924 kB
Inactive(anon):  5085572 kB
Active(file):    4663200 kB
Inactive(file): 61491112 kB
Unevictable:      347136 kB
Mlocked:          347136 kB
SwapTotal:      25165820 kB
SwapFree:       24892344 kB
Dirty:              4444 kB
Writeback:             0 kB
AnonPages:      24014904 kB
Mapped:         23040796 kB
Shmem:          37860316 kB
Slab:            1418188 kB
SReclaimable:     958620 kB
SUnreclaim:       459568 kB
KernelStack:       26880 kB
PageTables:      1871460 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    97907480 kB
Committed_AS:   78301368 kB
VmallocTotal:   34359738367 kB
VmallocUsed:     1053720 kB
VmallocChunk:   34358648516 kB
HardwareCorrupted:     0 kB
HugePages_Total:   57984
HugePages_Free:     5085
HugePages_Rsvd:     5082
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        6144 kB
DirectMap2M:     2082816 kB
DirectMap1G:    266338304 kB

Verifique se o item de HugePages_Total está com o valor configurado.

Para validar o limite de alocação de memória do usuário oracle, logue-se com ele e use o comando abaixo:

# ulimit -l

Verifique se o valor retornado é igual ao configurado.

Agora basta configurar o Oracle.

Configurando o Oracle

No Oracle é necessário desabilitar o Automatic Memory Management (AMM). Esse recurso que simplifica o gerenciamento de memória da instância, ajustando automaticamente os tamanhos da SGA e da PGA, não é compatível com HugePages.

Nota: O AMM foi introduzido na versão 11g, portanto se você está configurando uma versão anterior não precisa se preocupar com ele.

Para desabilitar o AMM, basta desconfigurar os parâmetros MEMORY_TARGET e MEMORY_MAX_TARGET, e configurar o SGA_TARGET, SGA_MAX_SIZE e PGA_AGGREGATE_TARGET.

SQL> show parameter target;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target                   integer     0
db_flashback_retention_target        integer     1440
fast_start_io_target                 integer     0
fast_start_mttr_target               integer     300
memory_max_target                    big integer 0
memory_target                        big integer 0
parallel_servers_target              integer     240
pga_aggregate_target                 big integer 6G
sga_target                           big integer 24G
SQL> show parameter sga
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 24G
sga_target                           big integer 24G

Se estiver usando uma versão de banco anterior à 11.2.0.3, precisa ter atenção redobrada na hora de configurar a quantidade/tamanho de HugePages, pois nessas versões não existe uso parcial de HugePages. Ou seja, versões até 11.2.0.2 tentam colocar a SGA inteira em HugePages, caso a quantidade não seja suficiente, a SGA será alocada integralmente em páginas normais.

A partir da versão 11.2.0.3 passa ser possível colocar apenas parte da SGA em HugePages, e a parte que sobrar é alocada em páginas regulares. Por exemplo, caso sua SGA seja de 32GB e o número de HugePages configurado some apenas 20GB, os 12GB excedentes serão alocados em páginas regulares.

Para verificar se a instancia iniciou usando corretamente as HugePages olhe o Alert log, conforme abaixo.

Starting ORACLE instance (normal)
****************** Large Pages Information *****************
Total Shared Global Region in Large Pages = 24 GB (100%)
Large Pages used by this instance: 12289 (24 GB)
Large Pages unused system wide = 3 (6144 KB) (alloc incr 64 MB)
Large Pages configured system wide = 57984 (113 GB)
Large Page size = 2048 KB
***********************************************************

Para facilitar o controle sobre quando a instância iniciou usando corretamente as HugePages e evitar que algo errado aconteça e somente seja percebido posteriormente, quando o banco estiver apresentando problemas de performance, na versão 11.2.0.2 foi criado o parâmetro USE_LARGE_PAGES.

Esse parâmetro poder ter os seguintes valores TRUE, FALSE e ONLY.

  • FALSE a instância nunca usará as HugePages.
  • TRUE a instância tentará usar as HugePages conforme descrito acima, podendo ser afetada pela configuração incorreta do número de HugePages e alocando a SGA de forma parcial ou total em páginas regulares.
  • ONLY a instância tentará alocar toda a SGA em HugePages, caso não consiga será gerado um erro e a instância não iniciará.

O erro gerado pelo parâmetro USE_LARGE_PAGES=ONLY é o seguinte:

SQL> startup
ORA-27137: unable to allocate large pages to create a shared memory segment
Linux-x86_64 Error: 12: Cannot allocate memory

Essa situação também pode ser verificada no Alert log.

****************** Large Pages Information *****************
Parameter use_large_pages = ONLY

Large Pages unused system wide = 0 (0 KB) (alloc incr 4096 KB)
Large Pages configured system wide = 0 (0 KB)
Large Page size = 2048 KB

ERROR:
  Failed to allocate shared global region with large pages, unix errno = 12.
  Aborting Instance startup.
  ORA-27137: unable to allocate Large Pages to create a shared memory segment

ACTION:
  Total Shared Global Region size is 24 GB. Increase the number of
  unused large pages to atleast 12289 (24 GB) to allocate 100% Shared Global
  Region with Large Pages.
***********************************************************

Usando esse parâmetro, você pode ter certeza que quando a instância inicia ela está efetivamente carregada em HugePages.

Criar ASM Diskgroups dentro de volumes NFS

Neste artigo vou abordar a utilização de arquivos em volumes NFS como discos ASM.
A ideia dessa configuração surgiu da minha necessidade de montar um ambiente de laboratório com Oracle 12c em RAC usando o Hyper-V do meu notebook.
Como o Hyper-V não suporta (até o momento em que este post foi criado, em 2016) o compartilhamento de discos entre VMs quando usados apenas discos locais, foi necessário buscar um método alternativo para criar o ambiente. Dessa forma, além das duas máquinas virtuais para os hosts do RAC, criei mais uma para ser o servidor NFS.

Nota: Apesar da utilização de arquivos em volumes NFS como discos ASM ser uma configuração suportada pela Oracle, ela deve ser utilizada com muita cautela, principalmente se pretende usá-la em produção. A utilização de volumes NFS requer a montagem no modo “hard”, o que faz com que a instância ASM ou o Database esperem indefinidamente por uma resposta do servidor NFS quando este ficar indisponível. Isso significa que o ASM não poderá fornecer de forma efetiva o espelhamento de dados.
De uma forma geral, para usar essa configuração os Diskgroups devem ser configurados com redundância “External” e a comunicação com os volumes NFS deve ser confiável.
Ref.:  How To Create ASM Diskgroups using NFS/NAS Files? (Doc ID 731775.1)

Configurando o servidor NFS (O Storage)

No ambiente de laboratório que estou montando o SO usado é o Oracle Linux 7, portanto todos os comandos aqui são relativos a essa versão, que trouxe varias novidades em relação ao Oracle Linux 6, principalmente a adição do systemd como mecanismo de controle e gerenciamento de serviços, devices, sockets e pontos de montagem.

Primeiramente instale o servidor NFS.

[root@ol7nfs01 ~]# yum install nfs-utils

Crie o diretório onde serão colocados os arquivos que serão usados como discos pelo ASM

[root@ol7nfs01 ~]# mkdir /nfs

Edite o arquivo /etc/exports para configurar a publicação do diretório pelo servidor NFS. Tenha atenção aos parâmetros usados e somente altere-os se souber o que está fazendo. Nesse laboratório o diretório que estou exportando é o “/nfs”.

[root@ol7nfs01 ~]# cat /etc/exports
/nfs    *(rw,sync,no_wdelay,insecure_locks,no_root_squash)

Inicie e ative o serviço do NFS, para que o mesmo inicie sempre que o servidor reiniciar.

[root@ol7nfs01 ~]# systemctl start nfs-server
[root@ol7nfs01 ~]# systemctl enable nfs-server

Configurando o cliente NFS (O Database Server)

A primeira atividade nos servidores de banco que montarão o diretório NFS é criar a pasta que servirá de ponto de montagem.

[root@ol7db01 ~]# mkdir -p /u01/oradata

Em seguida edite o arquivo /etc/fstab para que o volume NFS seja montado sempre que o servidor for reiniciado. Adicione a seguinte linha ao fstab, sendo que “ol7nfs01” é o nome do servidor NFS. Novamente atenção aos parâmetros e somente altere-os se souber o que está fazendo.

ol7nfs01:/nfs    /u01/oradata    nfs     rw,bg,hard,nointr,tcp,vers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0  0 0

Agora você pode montar o volume NFS

[root@ol7db01 ~]# mount -a

Em seguida configure o “ownership” e as permissões do diretório. Estou assumindo que o usuário oracle e o grupo oinstall já estão criados.

[root@ol7db01 ~]# chown -R oracle:oinstall /u01/oradata
[root@ol7db01 ~]# chmod -R 775 /u01/oradata

O próximo passo é criar os arquivos que serão usados como discos para o ASM. Vou criar alguns arquivos de 10 GB para usar nos diskgroups DATA e RECO. Como no meu laboratório vou instalar o Grid Infrastructure sob o usuário grid, usarei ele para criar os arquivos.

[grid@ol7db01 ~]$ mkdir /u01/oradata/asm
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data01.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data02.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data03.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data04.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/data05.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/reco01.disk bs=1k count=10000000
[grid@ol7db01 ~]$ dd if=/dev/zero of=/u01/oradata/asm/reco02.disk bs=1k count=10000000

Devemos ajustar novamente as permissões no diretório e arquivos criados.

[grid@ol7db01 ~]$ chmod 775 /u01/oradata/asm
[grid@ol7db01 ~]$ chmod 664 /u01/oradata/asm/*

Agora o ambiente já está preparado e podemos iniciar a instalação do Grid Infrastructure. Na tela de criação do diskgroup do ASM inicialmente não vão aparecer os discos candidatos. Basta clicar em “Change Discovery Path” e indicar o diretório NFS onde foram criados os arquivos.

Na tela para alterar o caminho de descoberta dos discos, digite o caminho com o asterisco como caractere coringa.

Quando retornar à tela de seleção de discos, os arquivos aparecerão listados.

Deste ponto em diante o processo é exatamente igual à qualquer instalação do Grid Infrastructure.

Converter um certificado PEM/CRT + KEY para PFX

Para converter um certificado que está no formato PEM/CRT juntamente com o arquivo de chave privada (KEY) em um arquivo PFX, que pode ser usado de forma mais simplificada em ambientes Windows/IIS, precisamos do OpenSSL. Caso esteja usando uma máquina com Linux, ele já estará disponível. Para instalar no Windows baixe a partir deste site.

O comando abaixo é que faz a mágica.

# openssl pkcs12 -export -out certificado.pfx -inkey privateKey.key -in certificado.pem -certfile CACert.crt

Onde:
– certificado.pfx: arquivo a ser gerado.
– certificado.pem: arquivo com o certificado no formato PEM. Pode estar com a extensão .crt também.
– privateKey.key: arquivo com a chave privada do certificado.
– CAcert.crt: arquivo com o certificado da entidade certificadora e os certificados intermediários. Este item não é obrigatório.

Obs.: um erro que costuma ocorrer é quando algum dos arquivos de entrada (pem, key ou crt) estão codificados com UTF8 BOM. O OpenSSL não consegue ler corretamente esse formato. Nesse caso edite o arquivo com algum editor de texto avançado, como o Notepad++, e altere a codificação para UTF8.

Configurando Proxy Reverso para Websocket no Apache

Em um post anterior mostramos como configurar o Apache como um Proxy Reverso, permitindo publicar sites hospedados em um servidor interno ou em sua DMZ externamente, sem expor diretamente esse servidor para acessos externos.

No entanto, caso a aplicação web hospedada no servidor de backend utilize o protocolo Websocket para manter uma conexão permanente entre cliente e servidor, são necessárias algumas configurações adicionais.

Basicamente, para que o Apache possa fazer corretamente o Proxy desse protocolo, é necessário utilizar o RewriteEngine para que quando seja identificado no cabeçalho HTTP enviado pelo cliente uma solicitação de “Upgrade” para Websocket, seja realizada a reescrita da requisição usando o endereço do servidor backend da aplicação.

RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "wss://localhost:8443%{REQUEST_URI}" [P,L]

As condições acima fazem simplesmente identificar no cabeçalho se os campos Upgrade e Connection foram definidos conforme a RFC que define o protocolo Websocket e faz a reescrita da URL da Request, trocando a parte do Host pelo endereço do servidor interno. No caso desse exemplo acima, o servidor de backend está no mesmo Host (localhost) mas em outra porta (8443).

Configurando Proxy Reverso no Apache

Existem diversas situações que podem requerer a configuração de um proxy reverso. As mais comuns que encontramos no nosso dia-a-dia são para criar uma camada adicional de proteção para um servidor que pode estar rodando um software mais antigo e não apresentar nível de segurança suficiente para ficar exposto na internet.

Outra situação é configurar um balanceamento de carga entre servidores de aplicação, ficando o proxy reverso na função de centralizar as conexões e distribuí-las para os servidores de aplicação disponíveis.

A configuração mais simples é a que possui apenas um servidor de aplicação como backend sendo acessado pelo proxy reverso. Sua configuração requer apenas as instruções abaixo.

ProxyPass "/" "http://localhost:8080/"
ProxyPassReverse "/" "http://localhost:8080/"

Essas instruções devem, preferencialmente, estar dentro de um VirtualHost, para evitar confusões com outros sites que o Apache possa estar servindo. Mas caso seja um servidor usado apenas para o proxy reverso de um site apenas, é possível colocar na sessão principal do httpd.conf.

O que essa instrução faz é passar todas as requisições para o backend. No entanto, é possível fazer proxy apenas de determinadas pastas.

ProxyPass "/imagens/" "http://localhost:8080/imagens/"
ProxyPassReverse "/imagens/" "http://localhost:8080/imagens/"

Nesse exemplo acima, no caso de uma requisição para http://www.exemplo.com.br/imagens/logo.png seria feito o proxy para o serviço rodando na porta 8080, mas uma requisição para http://www.exemplo.com.br/index.php seria servido pelo próprio Apache local.

Uma questão importante é que os diretórios do proxy e do backend não precisam ser sempre iguais.

ProxyPass "/" "http://localhost:8080/site/"
ProxyPassReverse "/" "http://localhost:8080/site/"

Nas instruções acima, um acesso ao endereço http://www.exemplo.com.br/index.php seria direcionado para o backend no caminho http://localhost:8080/site/index.php

Isso é bastante útil e permite inclusive que caminhos diferentes da URL sejam servidos por servidores backend diferentes.

Atualizando Hosts Standalone do VMware ESXi

Quando se está utilizando o VMware ESXi como virtualizador sem o auxilio do vCenter para fazer a gestão, o processo de atualização e aplicação de patches pode ser um pouco complicada. Nesse post vou mostrar duas formas de fazer essa atualização.

As duas formas precisam ser executadas via linha de comando no host, portanto habilite o acesso SSH no ESXi antes de iniciar.

Também é necessário que o host esteja em modo de manutenção e todas as VMs desligadas.

A primeira forma, que teoricamente é a mais simples, envolve atualizar automaticamente baseado no profile do host.

Identifique a versão atual do VMware ESXi:

# esxcli system version get

Depois verifique qual o Image Profile do Host:

# esxcli software profile get

Habilite o acesso internet a partir do host ESXi, liberando nas regras de firewall local. Caso necessário, libere também o acesso no seu firewall de borda.

# esxcli network firewall ruleset set -e true -r httpClient

Para atualizar o ESXi a partir do repositório online, utilize o comando abaixo:

# esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.7.0-20190402001-standard

Onde o parâmetro “-p” especifica o Image Profile que foi identificado no passo anterior.

O segundo modo é semelhante, mas ao invés de fazer a atualização a partir do repositório remoto, deve-se primeiro baixar o arquivo (bundle) de atualização e aplicá-lo.

Depois de baixar, coloque o arquivo .zip do bundle de atualização em um datastore do host e utilize o comando de “vib update” passando no parâmetro “-d” o caminho do arquivo de bundle.

# esxcli software vib update -d /vmfs/volumes/5cb37c65-0d32cf9e-7ed2-984be1791ea8/VIB/ESXi670-202004002.zip

Depois da atualização deverá ser realizado um reboot no host.

Configurar RedHat 5 para utilizar o repositório do CentOS 5 no Vault

Antes de mais nada é preciso dizer que não é recomendado utilizar uma versões tão antiga do RedHat/CentOS, principalmente se ela estiver acessível publicamente na Internet, visto que são versões já sem suporte à algum tempo e que não estão recebendo atualizações de segurança que podem ser críticas.

Mas se por qualquer necessidade você precisa utilizar essa versão, este procedimento pode ser útil. Principalmente se você utiliza o RedHat e não possui uma subscription ativa.

Aviso: Não execute esse procedimento em instalações RedHat que estejam em produção. Apesar do CentOS ser teoricamente uma ‘cópia’ do RedHat, compilado a partir dos mesmos códigos fonte, ainda assim é possível que em nível binário existam diferenças que quebrem a aplicação que está rodando no servidor.

Limpando cache local do yum:

# yum clean all

Baixando pacotes mais recentes do release do CentOS 5, do YUM e da lista de mirrors:

# wget http://vault.centos.org/5.11/os/x86_64/RPM-GPG-KEY-CentOS-5
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/centos-release-5-11.el5.centos.x86_64.rpm
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/centos-release-notes-5.11-0.x86_64.rpm
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/yum-3.2.22-40.el5.centos.noarch.rpm 
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/yum-updatesd-0.9-6.el5_10.noarch.rpm
# wget http://vault.centos.org/5.11/os/x86_64/CentOS/yum-fastestmirror-1.1.16-21.el5.centos.noarch.rpm

Importando a chave GPG do CentOS:

# rpm --import RPM-GPG-KEY-CentOS-5

Removendo o pacote de release dele do RedHat, pois será substituído pelo do CentOS:

# rpm -e --nodeps redhat-release

Instalar os pacotes baixados:

# rpm -Uvh --force yum*.rpm centos*.rpm

Atualizando o arquivo de repositório Base com as informações do repositório do Vault.

# head -37 /etc/yum.repos.d/CentOS-Vault.repo > /etc/yum.repos.d/CentOS-Base.repo
# sed -i 's/enabled=0/enabled=1/g' /etc/yum.repos.d/CentOS-Base.repo

Removendo arquivo desnecessário com as informações do Vault para evitar conflitos:

# rm -f /etc/yum.repos.d/CentOS-Vault.repo

Em seguida já pode rodar o yum para instalar os pacotes necessários, como por exemplo:

# yum install net-snmp

Converter um certificado PFX para o formato PEM

Podemos converter um arquivo de certificado PFX em dois tipo de arquivos PEM: deixando o certificado e a chave privada no mesmo arquivo, conhecido como PEM combinado, ou separando o certificado e a chave privada em arquivos separados. Nos dois casos iremos utilizar o utilitário OpenSSL que possui compilações tanto para Linux quando para Windows.

Para converter um certificado PFX em um arquivo PEM combinado, utilize o comando abaixo.

# openssl pkcs12 -in certificado.pfx -out certificado.pem -nodes

Onde:
– certificado.pfx: o arquivo de entrada no formato PFX.
– certificado.pem: o arquivo PEM que será gerado, contendo tanto o certificado quando a chave privada.

Para converter o certificado PFX para arquivos PEM separados (certificado + chave privada), utilize os comandos abaixo.

Extraindo a chave privada:

# openssl pkcs12 -in certificado.pfx -nocerts -out certificado.key -nodes

Onde:
– certificado.pfx: o arquivo de entrada no formato PFX.
– certificado.key: o arquivo gerado com a chave privada do certificado.

Extraindo o certificado:

# openssl pkcs12 -in certificado.pfx -clcerts -nokeys -out certificado.pem

Onde:
– certificado.pfx: o arquivo de entrada no formato PFX.
– certificado.pem: o arquivo que será gerado com o certificado no formato PEM.

Obs.: Importante ressaltar que os arquivos PEM gerados com a chave privada não estarão protegidos por senha devido ao uso do parâmetro “-nodes”.

Building a Self-Service, Secure, & Continually Compliant Environment on AWS

by Japjot Walia and Jonathan Shapiro-Ward

Introduction

If you’re an enterprise organization, especially in a highly regulated sector, you understand the struggle to innovate and drive change while maintaining your security and compliance posture. In particular, your banking customers’ expectations and needs are changing, and there is a broad move away from traditional branch and ATM-based services towards digital engagement.

With this shift, customers now expect personalized product offerings and services tailored to their needs. To achieve this, a broad spectrum of analytics and machine learning (ML) capabilities are required. With security and compliance at the top of financial service customers’ agendas, being able to rapidly innovate and stay secure is essential. To achieve exactly that, AWS Professional Services engaged with a major Global systemically important bank (G-SIB) customer to help develop ML capabilities and implement a Defense in Depth (DiD) security strategy. This blog post provides an overview of this solution.

The machine learning solution

The following architecture diagram shows the ML solution we developed for a customer. This architecture is designed to achieve innovation, operational performance, and security performance in line with customer-defined control objectives, as well as meet the regulatory and compliance requirements of supervisory authorities.

Machine learning solution developed for customer

This solution is built and automated using AWS CloudFormation templates with pre-configured security guardrails and abstracted through the service catalog. AWS Service Catalog allows you to quickly let your users deploy approved IT services ensuring governance, compliance, and security best practices are enforced during the provisioning of resources.

Further, it leverages Amazon SageMakerAmazon Simple Storage Service (S3), and Amazon Relational Database Service (RDS) to facilitate the development of advanced ML models. As security is paramount for this workload, data in S3 is encrypted using client-side encryption and column-level encryption on columns in RDS. Our customer also codified their security controls via AWS Config rules to achieve continual compliance

Compute and network isolation

To enable our customer to rapidly explore new ML models while achieving the highest standards of security, separate VPCs were used to isolate infrastructure and accessed control by security groups. Core to this solution is Amazon SageMaker, a fully managed service that provides the ability to rapidly build, train, and deploy ML models. Amazon SageMaker notebooks are managed Juypter notebooks that:

  1. Prepare and process data
  2. Write code to train models
  3. Deploy models to SageMaker hosting
  4. Test or validate models

In our solution, notebooks run in an isolated VPC with no egress connectivity other than VPC endpoints, which enable private communication with AWS services. When used in conjunction with VPC endpoint policies, you can use notebooks to control access to those services. In our solution, this is used to allow the SageMaker notebook to communicate only with resources owned by AWS Organizations through the use of the aws:PrincipalOrgID condition key. AWS Organizations helps provide governance to meet strict compliance regulation and you can use the aws:PrincipalOrgID condition key in your resource-based policies to easily restrict access to Identity Access Management (IAM) principals from accounts.

Data protection

Amazon S3 is used to store training data, model artifacts, and other data sets. Our solution uses server-side encryption with customer master keys (CMKs) stored in AWS Key Management Service (SSE-KMS) encryption to protect data at rest. SSE-KMS leverages KMS and uses an envelope encryption strategy with CMKs. Envelop encryption is the practice of encrypting data with a data key and then encrypting that data key using another key – the CMK. CMKs are created in KMS and never leave KMS unencrypted. This approach allows fine-grained control around access to the CMK and the logging of all access and attempts to access the key to Amazon CloudTrail. In our solution, the age of the CMK is tracked by AWS Config and is regularly rotated. AWS Config enables you to assess, audit, and evaluate the configurations of deployed AWS resources by continuously monitoring and recording AWS resource configurations. This allows you to automate the evaluation of recorded configurations against desired configurations.

Amazon S3 Block Public Access is also used at an account level to ensure that existing and newly created resources block bucket policies or access-control lists (ACLs) don’t allow public access. Service control policies (SCPs) are used to prevent users from modifying this setting. AWS Config continually monitors S3 and remediates any attempt to make a bucket public.

Data in the solution are classified according to their sensitivity that corresponds to your customer’s data classification hierarchy. Classification in the solution is achieved through resource tagging, and tags are used in conjunction with AWS Config to ensure adherence to encryption, data retention, and archival requirements.

Continuous compliance

Our solution adopts a continuous compliance approach, whereby the compliance status of the architecture is continuously evaluated and auto-remediated if a configuration change attempts to violate the compliance posture. To achieve this, AWS Config and config rules are used to confirm that resources are configured in compliance with defined policies. AWS Lambda is used to implement a custom rule set that extends the rules included in AWS Config.

Data exfiltration prevention

In our solution, VPC Flow Logs are enabled on all accounts to record information about the IP traffic going to and from network interfaces in each VPC. This allows us to watch for abnormal and unexpected outbound connection requests, which could be an indication of attempts to exfiltrate data. Amazon GuardDuty analyzes VPC Flow Logs, AWS CloudTrail event logs, and DNS logs to identify unexpected and potentially malicious activity within the AWS environment. For example, GuardDuty can detect compromised Amazon Elastic Cloud Compute (EC2) instances communicating with known command-and-control servers.

Conclusion

Financial services customers are using AWS to develop machine learning and analytics solutions to solve key business challenges while ensuring security and compliance needs. This post outlined how Amazon SageMaker, along with multiple security services (AWS Config, GuardDuty, KMS), enables building a self-service, secure, and continually compliant data science environment on AWS for a financial service use case.

Original em: https://aws.amazon.com/blogs/architecture/building-a-self-service-secure-continually-compliant-environment-on-aws/

Linux: Alterando discos e partições sem reiniciar

Caso tenha alterado o tamanho de um disco, por exemplo, aumentando o tamanho de um disco já existente em uma VM, use o comando abaixo para forçar o kernel do linux a reler as informações do disco.

# echo 1 > /sys/class/block/sdd/device/rescan

Sendo que “sdd” no comando acima é o dispositivo do disco que teve o tamanho alterado.

Caso tenha incluído ou removido um ou mais discos do servidor, utilize o comando abaixo para forcar uma releitura nos barramentos das controladoras por alterações de dispositivos. É importante ressaltar que o comando abaixo não tem nenhum efeito no caso de alteração de tamanho para um disco já reconhecido previamente pelo sistema.

# for host in /sys/class/scsi_host/*; do echo "- - -" | tee $host/scan; lsblk -S ; done

Após utilizar os comandos acima e os discos estarem devidamente reconhecidos com os tamanhos corretos, é possível seguir com a criação e/ou redimensionamento do sistema de arquivos.