2. Relevância do IaC para os DMIA

Infrastructure as Code:
É a prática de definir, versionar, revisar, testar e implantar infraestrutura por código. 

Em vez de configurar manualmente servidores, redes, permissões, bancos de dados, clusters Kubernetes 
ou serviços em nuvem, a equipe descreve esses recursos em arquivos declarativos ou scripts, como:
1. Terraform, 
2. Ansible, 
3. CloudFormation, 
4. Pulumi, 
5. Helm,
6. manifests Kubernetes. 

Essa abordagem trata a infraestrutura como software, permitindo: 

•	controle de versão, 
•	revisão por pares, 
•	testes automatizados, 
•	análise estática, 
•	auditoria, 
•	aprovação formal, 
•	rollback,
•	integração com pipelines CI/CD.

Para DMIA, essa mudança é decisiva: o dispositivo depende de um 
ecossistema reproduzível, auditável e seguro desde a origem. 

Sem isso, pode ser clinicamente promissor, mas digitalmente perigoso.

A literatura técnica mostra que scripts de IaC podem conter defeitos de sintaxe 
e configuração, gerando discrepâncias e indisponibilidades em escala. 

Em saúde, pode deixar de ser falha técnica e tornar-se risco assistencial quando 
há ausência de:
1.	monitoramento,
2.	autenticação, 
3.	telemetria,
4.	inferência clínica 

Assim, aplicar IaC a DMIA não é apenas produtividade: é segurança clínica.

3. Shift Left Security

O Shift Left Security antecipa a segurança para as fases iniciais do desenvolvimento.
Em vez de testar vulnerabilidades apenas no fim ou em produção, a equipe incorpora
verificações desde o (a):
•	desenho, 
•	codificação, 
•	versionamento, 
•	pipeline, 
•	build, 
•	testes,
•	implantação.

- A OWASP DevSecOps Guideline promove essa cultura nos processos de 
desenvolvimento, com práticas e ferramentas para pipelines seguros. 

- O National Institute of Standards and Technology (NIST) e o NIST Secure 
Software Development Framework também recomenda práticas de desenvolvimento 
seguro integráveis a diferentes ciclos de vida de software.

- No contexto dos DMIA, Shift Left Security significa que a segurança deve começar
antes da primeira implantação no paciente, o que inclui:
•	modelagem de ameaças antes da arquitetura final;
•	revisão de permissões antes da criação do ambiente;
•	análise de arquivos IaC antes do merge;
•	bloqueio automático de configurações inseguras;
•	detecção de segredos antes do commit;
•	varredura de imagens de containers antes do deploy;
•	análise de dependências antes da liberação;
•	verificação de criptografia antes do armazenamento de dados;
•	validação de logs antes da operação clínica;
•	criação de evidências auditáveis antes da submissão regulatória.

Em DMIA, o Shift Left Security pode ser compreendido como uma forma de
pré-tecnovigilância computacional. 

Ele procura identificar falhas antes que elas se manifestem no ambiente assistencial.

4. Policy as Code

•	O IaC descreve a infraestrutura. 
•	O Policy as Code descreve as regras que essa infraestrutura deve obedecer.

Em um ambiente de DMIA, não basta criar servidores, bancos, redes e 
permissões automaticamente. 

É necessário garantir que nenhuma infraestrutura seja criada fora de padrões 
mínimos de segurança. 

Para isso, políticas podem ser codificadas e aplicadas automaticamente em pipelines.

Exemplos de políticas aplicáveis a DMIA:
•	nenhum banco de dados clínico pode ser criado sem criptografia em repouso;
•	nenhum bucket pode ser público;
•	nenhuma API de inferência clínica pode aceitar tráfego sem TLS;
•	nenhum serviço administrativo pode estar exposto à internet;
•	nenhuma credencial pode estar hardcoded no repositório;
•	nenhuma imagem de container pode ser implantada com vulnerabilidade crítica conhecida;
•	nenhum serviço deve operar sem logs habilitados;
•	nenhum recurso deve ser criado sem tag de proprietário, finalidade clínica e criticidade;
•	nenhum ambiente de produção pode ser alterado sem revisão e aprovação;
•	nenhum DMIA pode acessar mais dados do que o necessário para sua função.

Com Policy as Code, a governança deixa de depender apenas de documentos internos e
passa a ser executada omputacionalmente. 

A regra deixa de ser apenas escrita. Ela passa a: 
1.	bloquear, 
2.	permitir, 
3.	alertar, 
4.	registrar,
5.	auditar.

Essa abordagem é especialmente relevante para DMIA, pois uma política institucional, por si só, 
não impede configurações inseguras. Quando incorporada ao pipeline, a política consegue bloquear 
vulnerabilidades antes que elas alcancem o ambiente de produção.

5. Responsabilidade regulatória

# 5.1 ANVISA 
A discussão sobre DMIA conecta-se ao conceito de Software as a Medical Device (SaMD). No Brasil, 
a RDC nº 657/2022 da Anvisa regula software como DM, e a Anvisa oferece perguntas e respostas 
para orientar sua aplicação.

# 5.2 FDA 
No cenário internacional, a FDA alerta que DMs conectados à internet, redes hospitalares e outros 
dispositivos ampliam riscos de cibersegurança capazes de afetar segurança e efetividade. 

A orientação da FDA sobre cibersegurança aborda para dispositivos com risco cibernético:
1.	projeto, 
2.	rotulagem,
3.	documentação em submissões pré-mercado.

# 5.3 IMDRF
O International Medical Device Regulators Forum (IMDRF) também publicou orientação sobre
SBOM para cibersegurança de DMs, destacando a transparência dos componentes de software.

Essas referências indicam uma mudança de paradigma: desenvolvedores de DMIA devem demonstrar 
ferramentas capazes de reduzir riscos cibernéticos ao longo do ciclo de vida do DM por meio das 
práticas que envolvem: 

•	funcionalidade,
•	concepção, 
•	construção, 
•	implantação,
•	manutenção. 

Nesse contexto, o IaC pode gerar evidências técnicas importantes:
•	histórico de alterações de infraestrutura;
•	trilhas de aprovação;
•	controles de acesso;
•	provas de criptografia;
•	evidências de segmentação;
•	relatórios de varredura;
•	logs de pipeline;
•	resultados de testes de conformidade;
•	inventário de recursos;
•	versionamento de políticas;
•	documentação técnica para auditoria.

Assim, o IaC deixa de ser apenas uma ferramenta de engenharia e passa a ser também 
uma ferramenta de governança sanitária.

6. A infraestrutura como extensão do risco clínico

Em medicina tradicional, o risco clínico costuma ser associado ao:
1.	erro diagnóstico, 
2.	erro terapêutico, 
3.	falha de equipamento, 
4.	evento adverso medicamentoso, 
5.	infecção relacionada à assistência,
6.	deterioração não reconhecida. 

Nos DMIA, surge uma camada adicional: o risco clínico induzido por infraestrutura 
digital, cujas origens podem ser:

•	interrupção de serviço que impede monitoramento em tempo real;
•	alteração de dados antes da inferência algorítmica;
•	vazamento de dados sensíveis;
•	acesso indevido a APIs clínicas;
•	indisponibilidade de modelos de IA;
•	manipulação de parâmetros do dispositivo;
•	uso de ambiente de teste em produção;
•	ausência de logs para investigação de incidente;
•	falha de autenticação entre dispositivo e nuvem;
•	uso de bibliotecas vulneráveis;
•	permissões excessivas para serviços automatizados.

A tese central deste artigo é que, em DMIA, infraestrutura insegura constitui vulnerabilidade clínica. 
Portanto, o desenvolvimento seguro desses dispositivos deve tratar a infraestrutura como parte
integrante do sistema médico. Ela passa a compor o risco assistencial sempre que participa de etapas como:

1.	coleta, 
2.	transmissão, 
3.	armazenamento, 
4.	processamento, 
5.	inferência, 
6.	exibição,
7.	acionamento de condutas.

7. Pipeline DevSecOps recomendado para DMIA com IaC

Um pipeline seguro para DMIA deve integrar etapas técnicas e regulatórias. 
Abaixo, propõe-se uma arquitetura conceitual mínima:

# 7.1. Planejamento e modelagem de ameaças
- Antes do código, a equipe deve mapear:
1. ativos, 
2. fluxos de dados, 
3. superfícies de ataque,
4. atores maliciosos, 
5. falhas previsíveis,
6. impactos clínicos. 

- A pergunta central não deve ser apenas “o sistema pode ser invadido?”
Ela passa a ser "qual dano ao paciente pode surgir se essa camada falhar?"

# 7.2. Codificação da infraestrutura
- A infraestrutura deve ser descrita em código, evitando configurações manuais não rastreáveis. 

- Ambientes de desenvolvimento, homologação e produção devem ser segregados e reproduzíveis.

# 7.3. Controle de versão e revisão por pares
- Todo arquivo IaC deve passar por revisão antes de ser incorporado. 

- Mudanças críticas em produção devem exigir aprovação formal e rastreável.

# 7.4. IaC scanning
Ferramentas de análise estática devem verificar configurações inseguras, como:
1.	portas abertas, 
2.	buckets públicos, 
3.	ausência de criptografia, 
4.	IAM permissivo, 
5.	imagens inseguras,
6.	logs desativados.

# 7.5. Secrets scanning
Não podem estar no repositório:
1.	credenciais, 
2.	tokens, 
3.	chaves privadas,
4.	senha. 

A OWASP possui recomendações específicas sobre gestão de segredos, 
destacando a necessidade de centralizar:
•	armazenamento,
•	provisionamento, 
•	auditoria, 
•	rotação,
•	controle de acesso a segredos.

# 7.6. Policy as Code
- Políticas de segurança devem bloquear automaticamente recursos fora do padrão. 

- Isso reduz dependência de revisão manual e torna a governança executável.

# 7.7. SAST, SCA, DAST e container scanning
O pipeline deve verificar:
•	código-fonte, 
•	dependências, 
•	APIs, 
•	imagens de containers,
•	bibliotecas. 

A OWASP DevSecOps Guideline inclui ferramentas e práticas relacionadas a: 
1. SAST, 
2. SCA,
3. IaC scanning.

# 7.8. SBOM e rastreabilidade
O DMIA deve possuir:
1.	inventário de componentes de software,
2.	bibliotecas, 
3.	imagens, 
4.	dependências,
5.	versões. 

Essa prática dialoga com o documento do IMDRF sobre Software Bill of Materials (SBOM) 
para cibersegurança de DM.

# 7.9. Deploy controlado
•	Alterações emergenciais devem gerar evidência 
•	Implantações em produção devem ser:
1.	automatizadas, 
2.	registradas,
3.	reversíveis..

# 7.10. Monitoramento contínuo e tecnovigilância computacional
- Após a implantação, o sistema deve ser monitorado. 

- Segurança antecipada não elimina a necessidade de vigilância posterior. 

- A FDA aponta a necessidade de planos para:
•	monitorar, 
•	identificar;
•	abordar vulnerabilidades.

Ela indica a importância de haver exploits pós-mercado, incluindo divulgação 
coordenada de vulnerabilidades e procedimentos relacionados.

8.1 Cenário Monitor cardíaco inteligente e bloqueio de bucket público

# Situação
Um hospital utiliza um DMIA de monitoramento cardíaco contínuo para pacientes em unidade
semi-intensiva. 

O dispositivo coleta frequência cardíaca, variabilidade do ritmo, saturação, sinais de alerta e eventos
sugestivos de arritmia.

Os dados são enviados para uma nuvem privada do fornecedor, 
onde um modelo de IA classifica padrões de risco e envia alertas ao painel da equipe assistencial.
Durante a implantação, um arquivo Terraform criou um bucket de armazenamento para logs e telemetria
clínica. 

Por erro de configuração, o bucket foi definido como público. Como o pipeline não possuía IaC scanning nem
Policy as Code, a configuração foi aprovada automaticamente.

# Vulnerabilidade
A vulnerabilidade principal é a exposição pública de dados clínicos sensíveis. Além 
disso, a ausência de criptografia adequada e a falta de bloqueio automatizado no pipeline indicam falha 
sistêmica de governança.

Possíveis impactos clínicos
•	vazamento de dados cardíacos identificáveis;
•	exposição de horários de internação e eventos fisiológicos;
•	risco de manipulação ou exclusão de registros;
•	perda de confiança institucional;
•	dificuldade de auditoria;
•	potencial comprometimento de decisões baseadas em histórico de telemetria.

# Mitigações propostas
1.	bloquear criação de buckets públicos por Policy as Code;
2.	exigir criptografia em repouso e em trânsito;
3.	habilitar logs de acesso;
4.	aplicar princípio do menor privilégio;
5.	usar classificação de dados clínicos;
6.	executar IaC scanning em pull requests;
7.	revisar infraestrutura por pares;
8.	habilitar alertas para alteração de permissões;
9.	manter evidências de conformidade para auditoria;
10.	incluir esse risco na matriz de tecnovigilância computacional.

# Lição aprendida
•	O dado fisiológico armazenado incorretamente é também parte do prontuário ampliado do
paciente.
•	Proteger a infraestrutura de armazenamento é proteger: 
1.	a dignidade, 
2.	a privacidade,
3.	a segurança clínica.

# Situação clínica-computacional
Um DMIA de monitoramento cardíaco envia telemetria para armazenamento em nuvem. 
O risco ocorre quando a infraestrutura é criada com um bucket público, expondo dados fisiológicos
sensíveis.

# Exemplo inseguro em Terraform

resource "aws_s3_bucket" "cardiac_telemetry" {
  bucket = "dmia-cardiac-telemetry"
}

resource "aws_s3_bucket_public_access_block" "cardiac_telemetry" {
  bucket = aws_s3_bucket.cardiac_telemetry.id

  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

# Problema
O código acima permite exposição pública. Em contexto comum, isso já seria grave. Em DMIA, 
torna-se ainda mais crítico porque os dados podem incluir:
1.	frequência cardíaca, 
2.	eventos arrítmicos, 
3.	horários de monitoramento, 
4.	estado clínico,
5.	metadados assistenciais.

# Exemplo seguro em Terraform

resource "aws_s3_bucket" "cardiac_telemetry" {
  bucket = "dmia-cardiac-telemetry-secure"

  tags = {
    Environment     = "production"
    ClinicalPurpose = "cardiac_monitoring"
    DataClass       = "sensitive_health_data"
    Owner           = "clinical_cybersecurity_team"
  }
}

resource "aws_s3_bucket_public_access_block" "cardiac_telemetry" {
  bucket = aws_s3_bucket.cardiac_telemetry.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "cardiac_telemetry" {
  bucket = aws_s3_bucket.cardiac_telemetry.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

resource "aws_s3_bucket_versioning" "cardiac_telemetry" {
  bucket = aws_s3_bucket.cardiac_telemetry.id

  versioning_configuration {
    status = "Enabled"
  }
}

# Policy as Code para bloquear bucket público

package dmia.iac.security

deny[msg] {
  input.resource_type == "aws_s3_bucket_public_access_block"
  input.block_public_acls == false
  msg := "DMIA Policy Violation: buckets com dados clínicos não podem permitir ACL pública."
}

deny[msg] {
  input.resource_type == "aws_s3_bucket_public_access_block"
  input.block_public_policy == false
  msg := "DMIA Policy Violation: política pública em bucket clínico é proibida."
}

deny[msg] {
  input.resource_type == "aws_s3_bucket"
  input.tags.DataClass == "sensitive_health_data"
  not input.encryption.enabled
  msg := "DMIA Policy Violation: dados sensíveis de saúde exigem criptografia."
}

Continua....

Continuação Cenário 8.1

# Pseudocódigo do pipeline seguro

on_pull_request(iac_change):

    run_terraform_validate()

    run_iac_security_scan()

    run_policy_as_code_checks()

    if bucket_is_public:
        block_merge("Bucket público proibido para dados clínicos")

    if encryption_is_missing:
        block_merge("Criptografia obrigatória para telemetria de DMIA")

    if clinical_tags_are_missing:
        block_merge("Recursos clínicos exigem tags de finalidade, dono e criticidade")

    require_security_review()

    approve_only_if_all_controls_pass()


# Princípio aplicado
O bucket que recebe telemetria cardíaca não é apenas um recurso de armazenamento. 
Ele é uma extensão digital do cuidado clínico. Portanto, deve nascer:
•	privado,
•	criptografado, 
•	auditável, 
•	bloqueado contra exposição pública.

8.2 Cenário Bomba de infusão inteligente e API administrativa exposta

# Situação
Uma rede hospitalar adota bombas de infusão inteligentes integradas a um sistema
central de prescrição eletrônica. 

As bombas recebem parâmetros autorizados, como:
1.	identificação farmacológica do medicamento,
2.	dose, 
3.	velocidade de infusão, 
4.	volume total,
5.	tempo de administração,
6.	dados dos profissionais envolvidos na assistência médica.  

•	O sistema possui uma API administrativa usada para atualização remota de configurações.
•	Durante a implantação em Kubernetes, um manifesto expôs temporariamente o serviço 
administrativo para a internet, com a justificativa de facilitar testes remotos. 
•	A regra deveria ser removida antes da produção, mas permaneceu ativa. 
•	O cluster não possuía validação automática contra exposição indevida de serviços críticos.

# Vulnerabilidade
A vulnerabilidade envolve:
1.	exposição de API administrativa sensível, 
2.	autenticação insuficiente,
3.	ausência de segmentação rígida entre ambiente de teste e produção.

# Possíveis impactos clínicos
•	alteração indevida de parâmetros de infusão;
•	interrupção remota do serviço;
•	risco de dose incorreta;
•	indisponibilidade de bombas em setores críticos;
•	geração de alarmes falsos;
•	atraso terapêutico;
•	necessidade de intervenção manual emergencial.

# Mitigações propostas
•	impedir exposição pública de APIs administrativas;
•	exigir autenticação forte e mTLS entre serviços;
•	aplicar segmentação de rede;
•	separar rigidamente ambientes de teste, homologação e produção;
•	usar admission controllers no Kubernetes;
•	bloquear portas e serviços inseguros por Policy as Code;
•	realizar DAST em APIs antes do deploy;
•	monitorar tráfego anômalo;
•	registrar mudanças de configuração;
•	criar procedimento de resposta rápida para incidentes em dispositivos críticos.

# Lição aprendida
•	Em DMIA terapêuticos, uma API exposta pode se tornar uma via indireta de 
dano medicamentoso. 
•	A segurança da interface administrativa deve ser tratada como componente 
da segurança farmacoterapêutica.

# Situação clínica-computacional
Uma bomba de infusão inteligente recebe comandos de configuração a partir de 
uma API administrativa. Durante testes, o serviço foi exposto à internet e a regra 
permaneceu em produção.

# Exemplo inseguro em Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: infusion-admin-api
  namespace: dmia-production
spec:
  type: LoadBalancer
  selector:
    app: infusion-admin-api
  ports:
    - protocol: TCP
      port: 443
      targetPort: 8443

# Problema
O tipo LoadBalancer pode expor a API administrativa fora da rede hospitalar 
ou fora da malha de serviços permitida. 

Em uma bomba de infusão, isso pode representar risco terapêutico direto.

# Exemplo seguro em Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: infusion-admin-api
  namespace: dmia-production
  labels:
    clinical-risk: high
    external-access: denied
spec:
  type: ClusterIP
  selector:
    app: infusion-admin-api
  ports:
    - protocol: TCP
      port: 443
      targetPort: 8443


Continua 

Continuação Cenário 8.2

# NetworkPolicy para restringir comunicação

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-infusion-admin-api
  namespace: dmia-production
spec:
  podSelector:
    matchLabels:
      app: infusion-admin-api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: authorized-clinical-controller
      ports:
        - protocol: TCP
          port: 8443
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: audit-log-service
      ports:
        - protocol: TCP
          port: 443


# Policy as Code para impedir exposição externa

package dmia.kubernetes.security

deny[msg] {
  input.kind == "Service"
  input.metadata.namespace == "dmia-production"
  input.spec.type == "LoadBalancer"
  input.metadata.labels["clinical-risk"] == "high"
  msg := "DMIA Policy Violation: serviços clínicos de alto risco não podem ser expostos como LoadBalancer."
}

deny[msg] {
  input.kind == "Service"
  input.metadata.namespace == "dmia-production"
  input.metadata.labels["external-access"] != "denied"
  msg := "DMIA Policy Violation: APIs administrativas de DMIA exigem external-access=denied."
}


# Python didático para autorização contextual de comando

from dataclasses import dataclass

@dataclass
class Actor:
    role: str
    mtls_verified: bool
    mfa_verified: bool

@dataclass
class Device:
    device_id: str
    assigned_patient_id: str
    allowed_ward: str

@dataclass
class Command:
    name: str
    risk level: str

@dataclass
class ClinicalContext:
    patient_id: str
    ward: str
    human_approval: bool
    emergency_mode: bool


def authorize_infusion_command(
    actor: Actor,
    device: Device,
    command: Command,
    context: ClinicalContext
) -> bool:
    if not actor.mtls_verified:
        return False

    if not actor.mfa_verified:
        return False

    if actor.role not in {"attending_physician", "authorized_clinical_controller"}:
        return False

    if device.assigned_patient_id != context.patient_id:
        return False

    if device.allowed_ward != context.ward:
        return False

    if command.risk_level == "high" and not context.human_approval:
        return False

    if command.name in {"increase_dose", "restart_infusion"} and not context.emergency_mode:
        return context.human_approval

    return True


# Princípio aplicado
A bomba pode ser inteligente, mas o comando terapêutico não deve ser livre. Ele deve depender de:
1.	identidade forte, 
2.	contexto clínico, 
3.	localização compatível, 
4.	paciente correto.
5.	aprovação humana proporcional ao risco.

8.3 Cenário IA radiológica com container vulnerável e modelo sem integridade verificável

# Situação
Um serviço de radiologia usa um DMIA com IA para triar exames de tórax, priorizando:
1. pneumotórax, 
2.	consolidações, 
3.	coleções,
4.	cavitações,
5.	nódulos,
6.	achados críticos. 

•	O modelo roda em containers e recebe imagens DICOM de um PACS hospitalar.
•	Uma atualização emergencial usou uma imagem de container antiga com vulnerabilidade crítica conhecida. 
•	O volume do modelo permitia escrita por serviço com permissões excessivas,
•	O pipeline não fazia:
1.	varredura de imagem, 
2.	assinatura de artefatos,
3.	validação de integridade do modelo.

# Vulnerabilidades
•	cadeia de suprimentos insegura
•	container vulnerável
•	ausência de assinatura de artefatos
•	permissões excessivas
•	risco de adulteração do modelo de IA

# Possíveis impactos clínicos
•	priorização incorreta de exames;
•	atraso na identificação de achados críticos;
•	falso negativo em condição urgente;
•	perda de integridade do modelo;
•	dificuldade de determinar origem do erro,
•	comprometimento da confiança.

# Mitigações propostas
•	realizar container scanning antes do deploy;
•	bloquear imagens com vulnerabilidades críticas;
•	assinar imagens e modelos;
•	validar hash do modelo antes da execução;
•	aplicar permissões somente leitura ao artefato de IA;
•	gerar SBOM do sistema;
•	registrar versão do modelo usada em cada inferência;
•	manter rollback seguro;
•	monitorar drift, performance e comportamento anômalo;
•	integrar tecnovigilância com auditoria de IA.

# Lição aprendida
•	Em DMIA baseados em IA, proteger o modelo é tão importante quanto proteger o dado. 
•	Um modelo adulterado ou executado em ambiente comprometido pode produzir uma
decisão aparentemente médica, mas tecnicamente contaminada.

# Situação clínica-computacional
•	Um DMIA radiológico usa IA para priorizar exames de tórax. 
•	O modelo roda em container e classifica imagens DICOM. 
•	O risco ocorre quando:
1.	a imagem de container está vulnerável,
2.	o arquivo do modelo pode ser substituído sem validação.

Continua 

Continuação Cenário 8.3

# Exemplo de pipeline inseguro
name: deploy-radiology-ai

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Build image
        run: docker build -t radiology-ai:latest .

      - name: Deploy to production
        run: kubectl apply -f k8s/deployment.yaml

# Problema
O pipeline acima constrói e implanta em produção sem:
1.	varredura de vulnerabilidades;
2.	validação de IaC;
3.	verificação de segredos;
4.	assinatura da imagem;
5.	SBOM;
6.	validação de integridade do modelo;
7.	aprovação humana para ambiente clínico.

# Pipeline seguro com Shift Left Security

name: secure-dmia-radiology-ai-pipeline

on:
  pull_request:
    branches:
      - main

jobs:
  security_checks:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Detect secrets
        run: |
          echo "Executar ferramenta de secrets scanning"
          echo "Bloquear tokens, senhas ou chaves privadas no repositório"

      - name: Validate Terraform
        run: |
          terraform fmt -check
          terraform validate

      - name: IaC security scan
        run: |
          echo "Executar scanner de IaC"
          echo "Bloquear portas públicas, IAM permissivo e ausência de criptografia"

      - name: Build container image
        run: docker build -t radiology-ai:${{ github.sha }} .

      - name: Container vulnerability scan
        run: |
          echo "Executar scanner de imagem"
          echo "Falhar se houver vulnerabilidade crítica"

      - name: Generate SBOM
        run: |
          echo "Gerar Software Bill of Materials"
          echo "Registrar bibliotecas, versões e dependências"

      - name: Verify model hash
        run: python scripts/verify_model_integrity.py

      - name: Require clinical security approval
        run: |
          echo "Deploy clínico exige aprovação de segurança e governança"


# Código para validação de integridade do modelo

Python

import hashlib
from pathlib import Path

APPROVED_MODEL_HASHES = {
    "radiology_triage_model_v1.4.2": "d4f6c3a8e5b9a2f9d2c7e4a1b0f8c6a9e7d5c3b2a1f0e9d8c7b6a5f4e3d2c1b0"
}


def calculate_sha256(file_path: str) -> str:
    sha256 = hashlib.sha256()
    path = Path(file_path)

    with path.open("rb") as model_file:
        for block in iter(lambda: model_file.read(4096), b""):
            sha256.update(block)

    return sha256.hexdigest()


def verify_model_integrity(model_name: str, model_path: str) -> bool:
    expected_hash = APPROVED_MODEL_HASHES.get(model_name)

    if expected_hash is None:
        raise ValueError("Modelo não aprovado para uso clínico.")

    actual_hash = calculate_sha256(model_path)

    if actual_hash != expected_hash:
        raise RuntimeError("Integridade do modelo violada. Deploy bloqueado.")

    return True


if __name__ == "__main__":
    verify_model_integrity(
        model_name="radiology_triage_model_v1.4.2",
        model_path="models/radiology_triage_model.bin"
    )
    print("Modelo validado. Integridade confirmada.")


# Código de governança do modelo

Json

{
  "model": {
    "name": "radiology_triage_model",
    "version": "1.4.2",
    "clinical_use": "prioritization_of_chest_imaging",
    "approved_for_production": true,
    "human_review_required": true
  },
  "security": {
    "artifact_signature_required": true,
    "sha256_required": true,
    "container_scan_required": true,
    "critical_vulnerabilities_allowed": false,
    "sbom_required": true
  },
  "audit": {
    "log_model_version_per_inference": true,
    "log_input_study_id": true,
    "log_output_risk_score": true,
    "log_human_override": true
  },
  "clinical_safety": {
    "autonomous_diagnosis_allowed": false,
    "triage_support_only": true,
    "radiologist_final_decision_required": true
  }
}

# Princípio aplicado
•	Em IA médica, o modelo é um ativo clínico. Se sua integridade não é verificável, 
sua inferência também não é plenamente confiável. 

•	O pipeline deve impedir que um modelo adulterado, vulnerável ou não aprovado seja 
implantado em ambiente assistencial.

8.4 Linguagem de Computação Aplicada aos Cenários de DMIA com IaC

Os cenários anteriores mostram que, em DMIA, vulnerabilidades podem surgir não só no algoritmo
clínico, mas também em:
1.	infraestrutura, 
2.	permissões, 
3.	serviços expostos, 
4.	containers, 
5.	criptografia,
6.	pipelines,
7.	políticas.

Por isso, DMIA devem incluir exemplos computacionais didáticos que convertam IaC, Policy as Code e Shift 
Left Security em barreiras técnicas concretas.

Os exemplos a seguir são fictícios, simplificados e educacionais, e exigem revisão especializada antes de qualquer 
uso em produção.

8.5 Matriz Computacional de Mitigação para DMIA com IaC

|Risco em DMIA|Falha de infraestrutura|Controle IaC / DevSecOps|Impacto clínico evitado|

|Vazamento de telemetria cardíaca|Bucket público|Terraform seguro + Policy as Code + criptografia|
|Exposição de dados fisiológicos|

|Comando indevido em bomba de infusão|API administrativa exposta|Kubernetes NetworkPolicy + mTLS + RBAC|
|Alteração terapêutica não autorizada|

|IA radiológica comprometida|Container vulnerável ou modelo adulterado|Container scanning + SBOM + hash do modelo|
|Priorização incorreta de exames|

|Acesso excessivo de serviço|IAM permissivo|Menor privilégio como código|Movimentação lateral e escalonamento|

|Deploy inseguro|Ausência de pipeline seguro|Shift Left Security no CI/CD|Falha antes da produção clínica|

|Falta de rastreabilidade|Alterações manuais|IaC versionado e auditável|Dificuldade de investigação pós-incidente|

8.6 Checklist Computacional para Criação Segura de DMIA com IaC

Json

{
  "dmia_secure_iac_checklist": {
    "infrastructure": [
      "usar infraestrutura como código",
      "proibir alterações manuais em produção",
      "versionar toda configuração crítica",
      "exigir revisão por pares"
    ],
    "security": [
      "aplicar shift left security",
      "executar iac scanning",
      "executar secrets scanning",
      "bloquear recursos públicos indevidos",
      "exigir criptografia em repouso e em trânsito"
    ],
    "policy_as_code": [
      "bloquear buckets públicos",
      "bloquear APIs administrativas expostas",
      "bloquear containers com vulnerabilidades críticas",
      "bloquear ausência de logs",
      "bloquear IAM permissivo"
    ],
    "clinical_governance": [
      "definir finalidade clínica do recurso",
      "classificar dados sensíveis",
      "exigir supervisão humana para ações críticas",
      "registrar versão do modelo por inferência",
      "manter trilha de auditoria"
    ],
    "technovigilance": [
      "monitorar vulnerabilidades pós-implantação",
      "manter SBOM atualizado",
      "registrar incidentes",
      "avaliar impacto clínico",
      "acionar plano de resposta"
    ]
  }
}

8.7 Pseudocódigo Geral do Pipeline Seguro para DMIA

on_dmia_infrastructure_change(request):

    identify_clinical_purpose(request)

    classify_data_sensitivity(request)

    validate_infrastructure_code()

    scan_for_secrets()

    scan_iac_misconfigurations()

    evaluate_policy_as_code()

    scan_container_images()

    generate_or_update_sbom()

    verify_model_integrity_if_ai_based()

    if critical_vulnerability_found:
        block_deployment()

    if public_exposure_detected:
        block_deployment()

    if missing_encryption:
        block_deployment()

    if excessive_privilege:
        block_deployment()

    if clinical_risk_high:
        require_human_security_approval()

    create_audit_evidence()

    deploy_only_if_all_controls_pass()

    start_continuous_monitoring()

    send_evidence_to_technovigilance_registry()

8.8 Síntese conceitual

A linguagem computacional fortalece o artigo ao transformar segurança em DMIA em:
1.	código, 
2.	política, 
3.	pipeline, 
4.	bloqueio, 
5.	auditoria,
6.	evidência.

O argumento central é direto:
Em DMIA, boas intenções não bastam: a segurança deve ser 
•	codificada, 
•	testada, 
•	bloqueada quando violada,
•	monitorada durante todo o ciclo clínico.

9. O conceito de tecnovigilância computacional

A tecnovigilância tradicional preocupa-se com eventos adversos, queixas técnicas, 
falhas de desempenho e riscos relacionados ao uso de produtos para saúde. Porém, 
os DMIA ampliam essa necessidade. 

Em DMIA conectados o evento adverso pode nascer de uma vulnerabilidade computacional. 

Por isso, propõe-se o conceito de tecnovigilância computacional, definida como o conjunto de
práticas destinadas a:
•	monitorar, 
•	detectar, 
•	analisar, 
•	mitigar,
•	documentar riscos digitais, que por sua vez podem afetar:
1.	a segurança, 
2.	o desempenho, 
3.	a confiabilidade, 
4.	a privacidade,
5.	a efetividade clínica de DMIA.

Ela deve incluir:
•	monitoramento de vulnerabilidades;
•	gestão de patches;
•	análise de logs;
•	detecção de anomalias;
•	rastreabilidade de versões;
•	SBOM atualizado;
•	resposta a incidentes;
•	avaliação de impacto clínico;
•	comunicação coordenada de vulnerabilidades;
•	revisão periódica de permissões;
•	auditoria de modelos de IA;
•	documentação regulatória;
•	aprendizado institucional pós-incidente.

Nesse modelo, o Shift Left Security atua antes da implantação, enquanto a tecnovigilância 
computacional atua depois da implantação. Ambos são necessários. 

# A fórmula proposta é:

DMIA seguro = Shift Left Security + Policy as Code + Mínimo Privilégio + SBOM + Monitoramento Contínuo 
+ Tecnovigilância Computacional

10. O princípio do menor privilégio como requisito clínico-cibernético

O princípio do menor privilégio determina que devem receber apenas as permissões necessárias à sua 
função cada:
•	usuário, 
•	serviço, 
•	aplicação, 
•	dispositivo, 
•	componente.

Em DMIA, esse princípio tem valor clínico: 
1.	bombas de infusão não precisam acessar dados radiológicos; 
2.	sistemas de triagem radiológica não devem alterar prescrições; 
3.	monitores cardíacos não devem escrever em tabelas administrativas;
4.	telemetria não deve modificar modelos de IA.

Permissões excessivas podem transformar uma falha local em dano sistêmico, possibilitando:
1.	escalonamento de privilégios, 
2.	acesso indevido, 
3.	alterações críticas.
4.	interrupção de serviços assistenciais.

No IaC, para que o menor privilégio se torne uma regra executável, não apenas uma 
recomendação, é necessário que as permissões ao violarem políticas devam ser:
•	declaradas, 
•	revisadas, 
•	testadas,
•	bloqueadas,.

11. Governança: da infraestrutura invisível à responsabilidade visível

Um dos principais desafios dos DMIA é tornar visível a infraestrutura que sustenta o cuidado. 
•	médicos observam alertas, 
•	pacientes interagem com dispositivos, 
•	gestores acompanham contratos,
•	reguladores analisam documentos; 

Ainda assim, a infraestrutura frequentemente permanece oculta.

O IaC torna essa infraestrutura verificável, ao: 
1.	registrar mudanças, 
2.	documentar aprovações, 
3.	versionar políticas, 
4.	reproduzir ambientes, 
5.	permitir auditoria das configurações.

O NIST Cybersecurity Framework 2.0 estrutura a cibersegurança nas funções:
•	Governar, 
•	Identificar, 
•	Proteger, 
•	Detectar, 
•	Responder,
•	Recuperar, 

Lógica aplicável aos DMIA: 
1. governar previamente, 
2. proteger durante a operação, 
3. detectar continuamente, 
4. responder com rapidez,
5. recuperar com segurança.

Na saúde, a governança da infraestrutura deve integrar a governança clínica. 
A questão deixa de ser apenas se o dispositivo é eficaz e passa a incluir se o 
ambiente digital é:
1. seguro, 
2. rastreável, 
3. resiliente,
4. auditável.

12. Proposta de princípios para DMIA seguros com IaC

Este artigo propõe dez princípios para orientar a criação de DMIA com IaC:

1. Tudo como código
Quando possível, devem ser tratado como código:
•	infraestrutura, 
•	políticas, 
•	permissões, 
•	redes, 
•	containers, 
•	monitoramento,
•	regras de segurança.

2. Segurança desde a concepção
A arquitetura do DMIA deve incorporar segurança antes da implantação, e não apenas após 
incidentes.

3. Política como barreira automática
Regras críticas devem bloquear configurações inseguras no pipeline.

4. Menor privilégio por padrão
Nenhum serviço deve receber permissão ampla por conveniência operacional.

5. Segredos nunca devem estar no código
Devem ser protegidos por sistemas próprios de gestão de segredos:
•	chaves, 
•	senhas, 
•	tokens,
•	certificados.

6. Ambientes devem ser segregados
Desenvolvimento, teste, homologação e produção não devem compartilhar:
•	permissões, 
•	dados sensíveis,
•	credenciais.

7. Toda implantação deve gerar evidência
Devem ser documentados automaticamente:
•	deploys, 
•	aprovações, 
•	testes,
•	exceções

8. O modelo de IA deve ser protegido como ativo clínico
Devem ter integridade verificável:
•	modelos, 
•	pesos, 
•	parâmetros,
•	versões.
9. O SBOM deve ser vivo
A lista de componentes deve ser mantida atualizada e conectada à gestão de vulnerabilidades.

10. Shift Left deve ser acompanhado de Shift Right
Ter em mente que segurança antecipada não substitui:
•	monitoramento, 
•	resposta a incidentes,
•	tecnovigilância pós-implantação.

13. Discussão crítica

1. A integração entre IaC, DMIA, segurança do paciente e tecnovigilância ainda é pouco explorada, 
embora represente uma lacuna relevante entre a literatura técnica e a área médica.

2. Essa lacuna é crítica, pois falhas como infraestrutura insegura, pipelines frágeis, APIs expostas, 
buckets públicos e modelos adulteráveis podem afetar pacientes antes de serem plenamente reconhecidas.

3. Assim, torna-se necessário reconhecer a infraestrutura clínica digital como dimensão própria da segurança 
clínico-cibernética. DMIA devem ser tratados como ecossistemas regulados, e não apenas como dispositivos
isolados.

14. Conclusão

1.	O Infrastructure as Code é essencial para DMIA seguros, pois torna a infraestrutura:
•	auditável,
•	integrada à proteção do paciente.

2.	Em DMIA, a infraestrutura não é mero suporte técnico: ela participa da:
•	segurança, 
•	confiabilidade, 
•	privacidade,
•	decisão clínica.

3.	Desenvolver DMIA sem IaC seguro amplia o risco assistencial por meio de:
•	falhas invisíveis,
•	configurações não controladas.


4.	Na medicina digital, a segurança do paciente também depende de:
•	pipelines, 
•	políticas automatizadas, 
•	logs, 
•	permissões,
•	evidências computacionais.

5.	Em síntese:
Proteger a infraestrutura digital é proteger o paciente.

15. Referências essenciais

1.	ANVISA. RDC nº 657/2022. Dispõe sobre a regularização de software como dispositivo médico.
2.	FDA. Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.
3.	FDA. Cybersecurity — Digital Health Center of Excellence.
4.	IMDRF. Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity.
5.	NIST. Secure Software Development Framework, SP 800-218.
6.	NIST. Cybersecurity Framework 2.0.
7.	OWASP. Infrastructure as Code Security Cheat Sheet.
8.	OWASP. DevSecOps Guideline.
9.	OWASP. Secrets Management Cheat Sheet. 
10.	Rahman A. et al. Bugs in Infrastructure as Code.
11.	Chiari M. et al. Static Analysis of Infrastructure as Code: a Survey. 

Oi, Ricardo! Tudo bem?

Seu infográfico está muito bem estruturado e demonstra um trabalho aprofundado ao conectar Infrastructure as Code (IaC), Shift Left Security, Policy as Code, DevSecOps e Dispositivos Médicos Inteligentes (DMIA). A organização em seções, o uso de exemplos práticos e a associação com referências como ANVISA, FDA e OWASP tornam o conteúdo consistente e facilitam a compreensão da proposta apresentada.

Como sugestão de melhoria, vale apenas observar que a quantidade de informações na mesma página é bastante elevada. Para facilitar a leitura, especialmente em telas menores, você pode aumentar um pouco o tamanho de algumas fontes, ampliar o espaçamento entre blocos e reduzir a quantidade de texto em determinados quadros, direcionando o leitor para o artigo completo quando desejar aprofundar o tema.

No geral, o material transmite uma mensagem importante: em ambientes que envolvem dispositivos médicos inteligentes, a segurança da infraestrutura também faz parte da segurança do paciente. É uma abordagem atual e que incentiva a integração entre computação, governança e saúde.

Parabéns pelo trabalho e por compartilhar esse conteúdo com a comunidade.

Quais outros desafios de cibersegurança em dispositivos médicos inteligentes você considera relevantes para aprofundar em um próximo estudo?

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Lorena, sua observação é pertinente. A densidade de informações é elevada, mas isso reflete um ponto crítico: em Medicina
e em IA, a simplificação excessiva é não apenas inadequada — é perigosa. A maior parte das discussões atuais sobre IA
aplicada à saúde ocorre em um nível superficial, como se fosse possível tratar fenômenos biológicos complexos com a mesma
linearidade de um fluxo computacional. Esse é, talvez, o risco mais subestimado.

A Medicina é uma ciência fundamentada em interações que começam no nível atômico e se manifestam em sistemas fisiológicos
altamente não lineares. Quando falamos de doenças, anormalidades ou ameaças biológicas, estamos lidando com processos que
envolvem moléculas, radicais livres, gradientes elétricos, osmolaridade, permeabilidade de membranas e cascatas bioquímicas que
não admitem reduções simplistas. Qualquer tecnologia que interfira, monitore ou responda a esses sistemas — especialmente um
DMIA jamais será trivial.

À medida que a IA avança, sua capacidade de identificar padrões aumenta, mas também aumenta a percepção das lacunas do
conhecimento. Descobertas que não podem ser reproduzidas permanecem como hipóteses, não como verdades. E isso é essencial:
IA não elimina incertezas; ela evidencia novas incertezas. Quanto mais poderosa, mais expõe o que ainda não sabemos.

Um DMIA que interage com o Sistema Nervoso Central, com a condução elétrica cardíaca ou com a cascata de coagulação não pode se
tratado como um corpo estranho passivo. Ele não pode alterar pH, interferir em atividade ciliar, modificar permeabilidade celular ou
gerar radicais livres. E isso é apenas o aspecto biológico. A camada cibernética adiciona um segundo eixo de risco, onde vulnerabilidades
digitais podem se traduzir em danos fisiológicos reais.

Por isso, o maior desafio não é apenas técnico — é epistemológico. É compreender que simplificar o que nunca será simples cria uma falsa
sensação de segurança. E essa ausência de percepção de risco é, paradoxalmente, o risco mais grave.

À medida que aprofundo meus estudos sobre IA aplicada à saúde, torna-se evidente que o perigo não está apenas no que descobrimos ou
achamos saber, mas na crença equivocada de que não há perigo algum.

Att,
Ricardo