2. Cenário SkyBank e transposição para a saúde

- A SkyBank, no exercício original, é uma startup financeira em fase inicial de implantação na nuvem. 

- A empresa representa um ambiente com dados de alto valor, exigências regulatórias e risco elevado 
de vazamento por erro de configuração. 

- A analogia com a saúde é direta: 

1. hospitais digitais, 

2. centros de diagnóstico, 

3. plataformas de telemedicina, 

4. repositórios de imagens, 

5. sistemas de apoio à decisão clínica, 

6. pipelines de IA,

7. dispositivos médicos inteligentes (DMIA) .

- Todos os itens supra citados necessitam de:

1. confidencialidade, 

2. integridade, 

3. disponibilidade, 

4. rastreabilidade,

5. governança de identidade.

2.1 Equivalência operacional

|SkyBank|Ambiente médico com IA|Risco equivalente|

|1 - Conta root usada para tudo|Conta administrativa hospitalar compartilhada|Comprometimento total 
do ambiente e perda de rastreabilidade|

|2 - Banco financeiro com IP público|Banco clínico ou repositório de exames exposto|Vazamento de dados 
sensíveis e interrupção assistencial|

|3 - Bucket público com documentos internos|Bucket com laudos, imagens ou datasets de treinamento|Exposição 
indevida, violação de confidencialidade e risco regulatório|

|4 - SSH aberto para o mundo|Acesso administrativo aberto a servidores hospitalares|Força bruta, ransomware, 
movimento lateral e indisponibilidade|

|5 - Permissão AdministratorAccess para analista|Permissão excessiva para usuário técnico ou integração|Escalada 
de privilégio, alterações indevidas e apagamento acidental|

2.2 Tese central

- Em ambientes críticos, segurança não é sinônimo de senha forte. 

- Senhas fortes podem falhar diante de arquitetura fraca. 

 - A proteção efetiva nasce da combinação de:

1. identidade, 

2. segmentação, 

3. criptografia, 

4. auditoria, 

5. menor privilégio, 

6. rastreabilidade,

7. redução de superfície de ataque. 

- Na Medicina Assistida por IA, essa arquitetura deixa de ser apenas boa prática computacional 
e se torna condição de segurança assistencial.

3. Arquitetura de referência

- A arquitetura proposta segue o padrão 3-Tier:

1. camada de apresentação/API em sub-rede pública controlada; 

2. camada de dados em sub-rede privada;

3. camada de governança com:

1. IAM, 

2. MFA,

3. políticas de menor privilégio, 

4. criptografia ,

5. auditoria de postura. 

- O banco de dados:

1. não deve possuir IP público,

2. não deve aceitar origem 0.0.0.0/0,

3. deve receber tráfego somente da camada web por referência ao 
Security Group autorizado.

3.1 Baseline de segurança

|Domínio|Controle mínimo|Critério de aprovação|

|1- Identidade|Root com MFA e uso excepcional|Nenhuma operação cotidiana executada como root|

|2 - Usuários|cloud-sec-admin com MFA; Developers com permissões limitadas|Cada ação
tem identidade individual rastreável|

|3 - Rede| PC 10.0.0.0/16 com sub-redes pública e privada|Sub-rede privada sem rota direta 
para IGW|

|4 - Firewall|Web-SG e Database-SG stateful|DB aceita apenas origem Web-SG|

|5 - Administração remota|SSH restrito ao IP pessoal /32 ou Session Manager|Porta 22 jamais 
aberta para 0.0.0.0/0|

|6 - Storage|Block Public Access e criptografia server-side|Acesso anônimo retorna Access Denied|

|7 - Auditoria|Checklist CSPM manual|Misconfigurations críticas identificadas e corrigidas|

4. Laboratório prático orientado

- As etapas abaixo podem ser executadas:

1. mentalmente, 

2. Vdocumentadas em portfólio,

3. realizadas em conta de testes.

- Para execução real, recomenda-se capturar evidências discretas: 

1. tela de MFA habilitado, 

2. grupos IAM sem credenciais sensíveis, 

3. rotas da sub-rede privada, 

4. regras de Security Groups, 

5. configuração de Block Public Access,

6. resultado de teste anônimo no bucket.

4.1 Etapa 1 — IAM Hardening

- Objetivo:
impedir que a conta root seja utilizada como identidade operacional e estabelecer usuários, 
grupos e permissões compatíveis com o princípio do menor privilégio.

- Passos recomendados: 

1.	Entrar com a conta root apenas para configuração inicial.

2.	Ativar MFA na conta root e guardar o método de recuperação de forma segura.

3.	Configurar alertas de faturamento para detecção precoce de uso inesperado.

4.	Criar o grupo Developers sem permissões administrativas amplas.

5.	Anexar política que permita gerenciamento limitado de computação e leitura 
de armazenamento, sem IAM e sem rede.

6.	Criar o usuário cloud-sec-admin, aplicar MFA e usá-lo para administração cotidiana.

7.	Encerrar sessão root e validar login com cloud-sec-admin.

Política conceitual para Developers

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowLimitedComputeManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowReadOnlyStorage",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::skybank-dados-confidenciais-*",
        "arn:aws:s3:::skybank-dados-confidenciais-*/*"
      ]
    },
    {
      "Sid": "DenyIdentityAndNetworkAdministration",
      "Effect": "Deny",
      "Action": ["iam:*", "ec2:CreateVpc", "ec2:DeleteVpc", "ec2:CreateSecurityGroup", "ec2:AuthorizeSecurityGroupIngress"],
      "Resource": "*"
    }
  ]
}

Interpretação

- A política acima é conceitual e conservadora.

- Em produção, permissões devem ser refinadas por:
1. recurso, 

2. tag, 

3. ambiente,

4. função,

5. necessidade real. 

- O ponto técnico é evitar AdministratorAccess para tarefas que
exigem apenas leitura ou operação controlada

Evidências sugeridas

•	Print da tela indicando MFA ativado para root, ocultando informações sensíveis.

•	Print do usuário cloud-sec-admin com MFA habilitado.

•	Print do grupo Developers com política limitada.

•	Teste negativo: usuário Developers não consegue criar usuário IAM ou deletar VPC.

4.2 Etapa 2 — Arquitetura de rede segura

- Objetivo: 

Criar uma rede isolada com segregação lógica entre camada pública e camada privada, 
garantindo que bancos de dados e serviços sensíveis não recebam conexões diretas da internet.

Desenho de rede

|Componente|Configuração sugerida|Propósito de segurança|

|1 - VPC|10.0.0.0/16|Isolar logicamente o ambiente da organização|

|2 - Sub-rede pública|10.0.1.0/24|Hospedar web/API/Load Balancer com rota controlada para IGW|

|3 - Sub-rede privada|10.0.2.0/24|Hospedar banco de dados sem IP público|

|4 - Internet Gateway|Associado apenas à rota pública|Permitir entrada controlada para camada web|

|5 - Route Table pública|0.0.0.0/0 → IGW|Tornar apenas a sub-rede pública alcançável|

|6 - Route Table privada|Sem rota direta para IGW|Impedir acesso direto ao banco pela internet|

Comandos conceituais AWS CLI

# Exemplo conceitual (não executar sem revisar região, custos e permissões):

aws ec2 create-vpc --cidr-block 10.0.0.0/16
aws ec2 create-subnet --vpc-id vpc-EXEMPLO --cidr-block 10.0.1.0/24
aws ec2 create-subnet --vpc-id vpc-EXEMPLO --cidr-block 10.0.2.0/24
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --vpc-id vpc-EXEMPLO --internet-gateway-id igw-EXEMPLO
aws ec2 create-route --route-table-id rtb-publica --destination-cidr-block 0.0.0.0/0 --gateway-id igw-EXEMPLO

Critério de aprovação

•	Instâncias na sub-rede privada não recebem IP público automaticamente.

•	A route table privada não contém rota 0.0.0.0/0 apontando para Internet Gateway.

•	O banco de dados, caso criado, não é publicamente acessível.

•	A topologia consegue ser explicada por camadas, e não por improviso operacional.

4.3 Etapa 3 — Firewalls e microsegmentação

- Objetivo: 
1. permitir que a camada web receba tráfego HTTP/HTTPS público, 

2. restringir SSH ao IP pessoal

3. permitir que o banco de dados aceite conexões apenas da camada web autorizada. 

- O ponto técnico mais relevante é usar o ID do Web-SG como origem do Database-SG, 
e não um IP amplo ou 0.0.0.0/0.

Matriz Securança de Grupo - Regra - Origem - Justificativa

|Security Group|Regra|Origem|Justificativa|

|1- Web-SG|TCP 80| 0.0.0.0/0|Permitir tráfego HTTP público quando necessário|

|2 - Web-SG|TCP 443|0.0.0.0/0|Permitir HTTPS público|

|3 - Web-SG|TCP 22|	Meu IP /32|	Reduzir risco de força bruta e varredura|

|4 - Database-SG|TCP 3306 ou 5432|ID do Web-SG|Permitir somente a camada web
autorizada|

|5 - Database-SG|Qualquer porta|0.0.0.0/0|Proibido: exposição direta do banco|

Exemplo conceitual de regras

# Web-SG: permitir HTTP/HTTPS publicamente e SSH apenas do IP pessoal.
aws ec2 authorize-security-group-ingress   --group-id sg-WEB   --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress   --group-id sg-WEB   --protocol tcp --port 22 --cidr MEU_IP_PUBLICO/32

# Database-SG: permitir PostgreSQL apenas a partir do Web-SG.
aws ec2 authorize-security-group-ingress   --group-id sg-DATABASE   --protocol tcp --port 5432 --source-group sg-WEB

Conceito-chave

- Ao referenciar o Web-SG como origem, a regra deixa de depender de IPs frágeis e passa 
a autorizar uma identidade lógica de rede. 

- Em termos práticos, apenas instâncias pertencentes ao grupo web podem falar com o banco.

4.4 Etapa 4 — Storage seguro e auditoria de postura

- Objetivo: 
Criar armazenamento com acesso público bloqueado, criptografia server-side e teste explícito 
de negação de acesso anônimo. 

- Esta etapa simula a lógica de um CSPM: 
1. inventariar, 

2. comparar com baseline, 

3. detectar falhas, 

4. corrigir,

5. evidenciar.

Baseline do bucket

•	Nome: skybank-dados-confidenciais-seunome, sem dados reais e 
sem informação sensível.

•	Block Public Access ativado em todas as opções.

•	Criptografia padrão server-side ativada.

•	Versionamento opcional para rastreabilidade de alterações.

•	Sem política pública e sem ACL pública.

•	Teste anônimo deve retornar Access Denied.

Comandos conceituais de proteção

aws s3api create-bucket --bucket skybank-dados-confidenciais-seunome

aws s3api put-public-access-block   --bucket skybank-dados-confidenciais-seunome   --public-access-block-configuration   BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-encryption   --bucket skybank-dados-confidenciais-seunome   --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]
  }'

5. Simulação de CSPM manual

- Um CSPM automatizado monitora continuamente configurações em nuvem e compara recursos 
com uma linha de base segura. 

- No Nível I, a simulação manual é suficiente para demonstrar raciocínio: 

1. procurar portas administrativas abertas, 

2. bancos públicos, 

3. buckets expostos, 

4. usuários excessivamente privilegiados,

5. ausência de criptografia. 

- O valor do exercício está na capacidade de reconhecer padrões de misconfiguration 
antes que se tornem incidentes.

Matriz Verificação - Auditoria - Resultados

|Verificação|Pergunta de auditoria|Resultado esperado|

| 1- IAM root|A conta root possui MFA e não é usada cotidianamente?|Sim|

|2 - Developers|O grupo consegue criar usuários IAM ou alterar VPC? |Não|

|3 - Sub-rede privada|Existe rota direta para Internet Gateway?|Não|

|4 - Database-SG|Existe regra 0.0.0.0/0?|Não|

|5 - Database-SG|A origem é o Web-SG?|Sim|

|6 - SSH|Porta 22 está aberta para a internet?|Não|

| 7 - Bucket|Block Public Access está ativo?|Sim|

|8- Bucket|Acesso anônimo abre ou baixa objeto?|Não|

|9 - Custos	|Instâncias, EIPs ou NAT Gateways foram removidos? |Sim, ao final|

5.1 Pseudocódigo de auditoria

função auditar_ambiente_cloud():
    verificar_mfa_root()
    verificar_usuarios_sem_credenciais_compartilhadas()
    verificar_politicas_com_administrator_access()
    para cada security_group:
        se porta in [22, 3389, 3306, 5432] e origem == "0.0.0.0/0":
            registrar_falha_critica(security_group)
    para cada subnet_privada:
        se rota_destino == "0.0.0.0/0" e target == "Internet Gateway":
            registrar_falha_critica(subnet_privada)
    para cada bucket:
        se block_public_access == falso ou criptografia == ausente:
            registrar_falha_critica(bucket)
    gerar_relatorio_de_postura()

5.2 Exemplo em Python para raciocínio de auditoria

O código abaixo é uma representação didática. Para uso real exigiria:

1. credenciais temporárias, 

2. perfil seguro, 

3. tratamento de paginação, 

4. logs, 

5. escopo por conta/região,

6. validação de permissões.

Exemplo didático: auditoria de Security Groups em AWS com boto3.

# Não inserir chaves no código. Usar IAM Role, SSO ou credenciais temporárias.

import boto3

PORTAS_CRITICAS = {22: "SSH", 3389: "RDP", 3306: "MySQL", 5432: "PostgreSQL"}

def auditar_security_groups(region="us-east-1"):
    ec2 = boto3.client("ec2", region_name=region)
    resposta = ec2.describe_security_groups()
    achados = []

    for sg in resposta.get("SecurityGroups", []):
        nome = sg.get("GroupName")
        sgid = sg.get("GroupId")
        for regra in sg.get("IpPermissions", []):
            porta = regra.get("FromPort")
            for faixa in regra.get("IpRanges", []):
                cidr = faixa.get("CidrIp")
                if porta in PORTAS_CRITICAS and cidr == "0.0.0.0/0":
                    achados.append({
                        "severity": "CRITICAL",
                        "security_group": nome,
                        "id": sgid,
                        "porta": porta,
                        "servico": PORTAS_CRITICAS[porta],
                        "problema": "Porta administrativa ou de banco aberta para internet"
                    })
    return achados

if __name__ == "__main__":
    for achado in auditar_security_groups():
        print(achado)

6. Sobre a Matriz ameaça → impacto clínico → controle recomendado

- A contribuição diferencial deste projeto é demonstrar que misconfigurations em nuvem 
não são apenas falhas técnicas. 

- Em saúde digital, elas podem produzir consequências:
1. clínicas, 

2. operacionais,

3. legais,

4. reputacionais. 

- A matriz abaixo traduz o raciocínio de Cloud Security para cenários de 
Medicina Assistida por IA.

Matriz ameaça → impacto clínico → controle recomendado

|Ameaça / falha	Impacto clínico-operacional	|Controle recomendado|

|1 - Root sem MFA| Comprometimento total de sistemas, interrupção assistencial e apagamento de evidências|
|MFA obrigatório, uso excepcional, alertas e cofre de credenciais|

|2 - Credenciais hardcoded| Vazamento de acesso a dados clínicos, modelos, imagens ou buckets| IAM Roles, 
credenciais temporárias, secret manager e rotação|

|3 - Banco com IP público|Exposição de prontuários, laudos, metadados e dados de treinamento|Sub-rede 
privada, SG por origem lógica e criptografia|

|4 - SSH aberto para 0.0.0.0/0|Acesso indevido, ransomware e movimento lateral|	IP /32, Bastion hardened, 
Session Manager e logs|

|5 - Bucket público| Vazamento de exames, relatórios e datasets sensíveis| Block Public Access, SSE, política
restritiva e auditoria contínua|

|6 - Permissão AdministratorAccess ampla| Alterações não autorizadas, erro humano e perda de governança| Least 
privilege, segregação de função e revisão periódica|

|7 - Ausência de CSPM| Misconfigurations permanecem invisíveis por dias ou semanas| Monitoramento contínuo, 
baseline e correção automatizada quando possível|

|8 - Falta de defesa em profundidade| Falha única se transforma em incidente sistêmico|Camadas: IAM, rede, WAF,
host, dados, logs e resposta|

7. Evidências para portfólio

- A parte prática ganha valor quando produz evidências verificáveis. 

- O objetivo não é mostrar credenciais, chaves ou identificadores sensíveis, mas demonstrar método, 
raciocínio e capacidade de implementação segura. 

- As evidências devem ser higienizadas antes de publicação.

7.1 Matriz Evidência - Exibição - Ocultação

|Evidência| O que mostrar| O que ocultar|

|1 - MFA root| Status de MFA habilitado|E-mail completo, Account ID, QR code e detalhes de recuperação|

|2 - IAM Developers	|Nome do grupo e política limitada|	ARNs completos se houver risco de identificação|

|3 - VPC|CIDR, sub-redes e route tables|IDs de conta e região sensível se aplicável|

|4 - Security Groups|Web-SG e Database-SG com regras corretas|IPs pessoais e identificadores 
não necessários|

|5 - Bucket	Block Public| Access e criptografia	|URL real se vinculada a conta pessoal|

|6 - Teste anônimo	|Access Denied|	Headers ou IDs completos|

|7 - Checklist|	Aprovação dos critérios|Dados internos ou credenciais|

8. Encerramento seguro de recursos

- A competência em Cloud Security também se revela no encerramento responsável do
laboratório. 

 - Recursos esquecidos podem gerar custos, ampliar superfície de ataque e criar riscos 
 desnecessários.

- Ao final, deve-se realizar uma limpeza explícita e documentada.
•	Terminar instâncias EC2/VMs criadas para teste.

•	Remover Elastic IPs não associados.

•	Excluir NAT Gateway, caso tenha sido criado, por seu potencial de custo.

•	Excluir buckets de teste após remover objetos e versões.

•	Remover Security Groups, sub-redes, route tables, Internet Gateway e VPC, se o laboratório 
for temporário.

•	Validar billing dashboard após algumas horas ou no dia seguinte.

•	Manter apenas documentação, prints higienizados e checklist de aprendizado.

8.1 Checklist final

|Controle	| Status esperado| 

|1 - Root protegido com MFA|Aprovado|

|2 - cloud-sec-admin com MFA|Aprovado|

|3 - Developers sem permissão IAM/VPC administrativa|Aprovado|

|4 - Sub-rede privada sem rota para IGW	|Aprovado|

|5 - Database-SG sem 0.0.0.0/0	|Aprovado|

|6 - Database-SG aceita origem Web-SG|Aprovado|

|7 - SSH restrito a IP pessoal /32 ou substituído por Session Manager|Aprovado|

|8 - Bucket com Block Public Access|Aprovado|

|9 - Bucket com criptografia server-side|Aprovado|

|10 - Recursos temporários excluídos|Aprovado|

9. Perspectiva evolutiva: do Nível I ao Nível II

- O Nível I consolida fundamentos essenciais: 

1. dentidade, 

2. rede,

3. firewall, 

4. storage,

5. postura. 

- A evolução natural é transformar essa arquitetura em Infraestrutura como Código, 
preferencialmente com Terraform, e inserir políticas automatizadas de compliance. 

- O objetivo deixa de ser apenas construir uma arquitetura segura manualmente e passa 
a ser reproduzi-la com:

1. consistência, 

2. versionamento, 

3. revisão por pares,

4. detecção precoce de desvios.

9.1 Esqueleto conceitual em Terraform

# Representação conceitual para estudo futuro no Nível II.

# Não executar sem backend, provider, variáveis, tags, revisão de custos e hardening.

resource "aws_vpc" "skybank" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "publica" {
  vpc_id     = aws_vpc.skybank.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_subnet" "privada" {
  vpc_id                  = aws_vpc.skybank.id
  cidr_block              = "10.0.2.0/24"
  map_public_ip_on_launch = false
}

resource "aws_security_group" "web_sg" {
  name   = "Web-SG"
  vpc_id = aws_vpc.skybank.id
}

resource "aws_security_group" "database_sg" {
  name   = "Database-SG"
  vpc_id = aws_vpc.skybank.id
}

# Regra conceitual: banco aceita apenas origem Web-SG.
resource "aws_security_group_rule" "db_from_web" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  security_group_id        = aws_security_group.database_sg.id
  source_security_group_id = aws_security_group.web_sg.id
}

10. Considerações finais

- O projeto SecureFoundation SkyBank demonstra que a segurança em nuvem 
começa antes da aplicação. Seu início se da:

1. na identidade, 

2. no desenho de rede, 

3. no isolamento das camadas, 

4. na restrição de tráfego, 

5. a proteção do armazenamento,

6. na capacidade de auditar continuamente a postura do ambiente. 

- Em uma leitura aplicada à saúde, esse raciocínio tem peso ainda maior, pois que uma 
configuração insegura pode deixar de ser simples erro técnico e se converter em risco para:

1. confidencialidade,

2. continuidade assistencial, 

3. governança clínica,

4. confiabilidade de sistemas médicos baseados em IA.

Ao concluir o Nível I com alto desempenho e transformar a prática opcional em documentação 
estruturada, o autor reforça uma trilha técnica rara e necessária: 

1. a aproximação entre Medicina, Inteligência Artificial, Cloud Security, Tecnovigilância e proteção 
de dados sensíveis. 

- A segurança de sistemas médicos contemporâneos não poderá depender exclusivamente de 
profissionais de tecnologia, nem poderá ser ignorada pelos profissionais da saúde. O valor está justamente 
na ponte entre esses mundos.

Referências e base de elaboração

•	Material do curso Checkpoint Cloud Security — Nível I, incluindo prova teórica, respostas comentadas e 
projeto prático SecureFoundation: Construindo uma nuvem blindada.

•	Princípios gerais de Cloud Security: Modelo de Responsabilidade Compartilhada, IAM, Least Privilege,
Defense in Depth, segmentação de rede, criptografia, auditoria de postura e CSPM.

•	Boas práticas conceituais aplicadas a AWS/Azure/GCP, adaptáveis conforme provedor, região, políticas 
institucionais e requisitos de conformidade.