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 Terraform, 
Ansible, CloudFormation, Pulumi, Helm ou 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. Isso 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 computacionalmente. 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 codificada no pipeline, a política pode bloquear vulnerabilidades antes que cheguem ao ambiente 
de produção.

Olá, Ricardo! Como vai?

Parabéns pela elaboração do artigo!

Vi que você explorou o Infrastructure as Code (IaC) para segurança em Dispositivos Médicos Inteligentes (DMIA), utilizou muito bem o conceito de Shift Left Security para antecipar vulnerabilidades e ainda compreendeu a importância da Policy as Code para governança automatizada em ambientes clínicos.

Continue compartilhando suas produções, com certeza isso ajuda outros profissionais e estudantes e tem grande relevância para o fórum.

Se quiser aprofundar ainda mais, algumas boas práticas são:

• Integração regulatória: alinhar IaC com requisitos da ANVISA, FDA e NIST.
• Automação segura: aplicar CI/CD com validações de segurança em cada etapa.
• Auditoria contínua: manter logs e evidências para tecnovigilância computacional.

Alguns materiais podem estar em inglês, mas é possível compreendê-los usando o recurso de tradução de páginas do próprio navegador.

Ah, uma pergunta: você prefere continuar aprofundando os fundamentos de IaC aplicados à saúde ou acha mais interessante avançar para estudos de caso práticos envolvendo DMIA em ambientes hospitalares simulados?

Fico à disposição! E se precisar, conte sempre com o apoio do fórum.

Abraço e bons estudos!

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

5. Responsabilidade regulatória

1. 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.

2. 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.

3. 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. 

Esse risco pode surgir de várias formas:
•	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.

Olá, Daniel.
Vi seus comentários e sua análise acima, e agradeço. Acontece que eu ainda não havia finalizado a publicação de todo o artigo. Como sua indagação está relacionada à continuação do conteúdo, e considero extremamente importante a análise de vocês sobre os códigos de computação, prefiro reiniciar a publicação.

Para evitar qualquer confusão, vou colocar como título deste artigo a frase “versão incompleta” e marcá-lo como solucionado. A nova publicação terá o título sem esse comentário.

Agradeço pela compreensão.
Ricardo