Gerenciamento de patches para MSP: Como manter todos os clientes protegidos
O gerenciamento de patches é um dos serviços de maior impacto oferecidos por um MSP. Ele funciona diariamente em segundo plano, atende a uma cláusula presente em quase todos os pedidos de seguro cibernético, está no centro das certificações de conformidade para clientes em setores regulamentados e, quando bem estruturado, contribui discretamente para a geração de receita recorrente. Além disso, a cada ano que passa, essa tarefa fica mais difícil, e não mais fácil.
A razão é estrutural. Uma equipe interna de TI aplica patches em um único ambiente, com um conjunto de pilhas de tecnologia, um conjunto de janelas de manutenção e um fluxo de trabalho de aprovação. Um MSP executa o mesmo roteiro cinquenta ou cem vezes em paralelo, em cinquenta ou cem ambientes diferentes que não compartilham uma única regra comum. Isso não é uma versão ampliada da aplicação de patches pela equipe interna de TI. É um modelo operacional diferente.
O software de gerenciamento de patches da Datto RMM foi desenvolvido para esse modelo operacional e é utilizado por milhares de MSPs para aplicar patches em milhões de terminais de clientes, oferecendo uma visão clara de onde os programas de patches dos MSPs se mantêm estáveis sob carga e onde apresentam falhas.
Este artigo explora por que a aplicação de patches é uma linha de serviços de MSP que merece ser levada a sério, o que torna a aplicação de patches em ambiente multitenant genuinamente diferente, o modelo operacional por trás de um programa eficaz e como os MSPs mais experientes estruturam e definem os preços desse trabalho.
Por que o gerenciamento de patches é uma linha de serviços de verdade para MSPs, e não apenas uma tarefa
Para a maioria dos MSPs, a aplicação de patches começou como um item de lista no contrato de gerenciamento de serviços ( managed services ). Ela estava incluída na taxa por terminal, era executada em segundo plano e aparecia nos relatórios mensais como uma porcentagem. Era um custo inerente à atividade, não um serviço em si.
Essa abordagem ficou ultrapassada. Três fatores fizeram com que a aplicação de patches saísse da área administrativa e passasse a ocupar um lugar central na forma como os MSPs vendem, prestam serviços e definem preços.
O primeiro é o seguro cibernético. Atualmente, as seguradoras tratam a aplicação de patches como um controle básico. Um SLA documentado para a aplicação de patches, comprovação de que CVEs críticos são corrigidos prontamente e uma varredura externa da superfície de ataque são itens padrão nos formulários de solicitação e questionários de renovação. O Índice Global do Mercado de Seguros da Marsh do segundo trimestre de 2025 registrou a nona redução trimestral consecutiva nas taxas de seguro cibernético comercial, em parte porque os controles melhoraram em toda a base de segurados. As seguradoras também estão realizando auditorias mais rigorosas no meio do prazo, com a frequência de aplicação de patches figurando entre os controles de alto impacto que determinam se um sinistro será indenizado. Um MSP capaz de apresentar, mediante solicitação, comprovantes de aplicação de patches por cliente está oferecendo algo substancialmente diferente daquele que não consegue fazê-lo.
O segundo aspecto são os dados sobre ameaças. Cerca de 50.000 CVEs foram publicados em 2025, um aumento de 22% em relação ao ano anterior, e cerca de 30% das vulnerabilidades listadas no catálogo de “Vulnerabilidades Exploradas Conhecidas” da CISA são transformadas em armas em até 24 horas após a divulgação. O prazo para um programa de aplicação de patches eficaz foi reduzido de semanas para dias. Para os MSPs que atendem pequenas e médias empresas sem recursos internos de segurança, essa redução torna a aplicação de patches a proteção mais econômica que o cliente pode adquirir.
O terceiro aspecto é a responsabilidade civil. O mercado de seguros de MSPs relata que uma parcela significativa desses prestadores de serviços tem apresentado reclamações relacionadas a ataques cibernéticos nos últimos anos, sendo que implementações malfeitas de patches e redes de clientes sem patches estão entre as categorias recorrentes de reclamações. O risco contratual é real. Um contrato de prestação de serviços (MSA) que prometa a aplicação de patches como parte do serviço, aliado a uma violação de segurança do cliente atribuível a um sistema sem patches, é exatamente o cenário no qual se baseia uma reclamação de responsabilidade civil profissional (Tech E&O).
Quando consideradas em conjunto, essas forças transformam o gerenciamento de patches de uma tarefa operacional secundária em uma linha de serviços completa, com seus próprios SLAs, pacote de evidências e preço. Os MSPs que realizaram essa transição estão obtendo margens mais saudáveis com a mesma base de clientes, pois cobram por um resultado (uma postura de patches justificável) em vez de uma atividade (execução de atualizações).
Para uma análise mais aprofundada dessa área, o guia da Kaseya sobre o que é gerenciamento de patches aborda os conceitos básicos nos quais o restante deste artigo se baseia.
O que torna o gerenciamento de patches do MSP realmente diferente
O conteúdo genérico sobre gerenciamento de patches trata o problema da multilocação como “aplicação de patches, mas com mais clientes”. Essa abordagem não leva em conta o que realmente muda. O trabalho não é maior. Ele é estruturalmente diferente nos cinco aspectos a seguir:
Pilhas diferentes por cliente
Uma única equipe interna de TI padroniza o uso de uma versão do sistema operacional, um navegador aprovado, um pacote de produtividade e algumas aplicações específicas de negócios. Um MSP que atende a cinquenta pequenas e médias empresas (PMEs) oferece suporte a cinquenta ambientes de aplicativos diferentes, desde o oftalmologista que utiliza um sistema especializado de gestão de consultório em um Windows Server mais antigo, passando pelo escritório de arquitetura que utiliza software CAD com dependências de drivers difíceis de resolver, até o escritório de advocacia cuja plataforma de gerenciamento de documentos deixa de funcionar se uma atualização específica do Office for instalada primeiro. A ferramenta de patches precisa lidar com essa diversidade sem forçar todos os clientes a seguirem o mesmo ciclo de atualizações.
Diferentes janelas de manutenção
Um cliente industrial aplica atualizações às 3h da manhã de domingo, pois esse é o único horário em que a linha de produção está parada. Um varejista aplica atualizações no meio da semana, pois o fim de semana é o pico de receita. Um consultório médico não pode reiniciar nenhuma estação de trabalho entre 8h e 18h. Cada cliente tem um horário disponível, e esses horários não coincidem. Aplicar um único cronograma de manutenção para todos é a maneira mais rápida de atrapalhar uma reunião com o cliente e perder a conta. A ferramenta deve gerenciar o cronograma por cliente, no horário local, com exceções para os casos inevitáveis.
Diferentes SLAs e fluxos de trabalho de aprovação
Alguns clientes desejam que todas as correções críticas sejam implantadas em até 48 horas, sem a necessidade de aprovação humana. Outros querem que seu diretor de TI (CIO) aprove antes que qualquer coisa chegue ao ambiente de produção. Um terceiro grupo possui estruturas de conformidade que exigem uma abordagem específica de implantação em etapas, com evidências documentadas dos testes. A aplicação de correções em ambiente multilocatário significa executar vários fluxos de trabalho de aprovação simultaneamente, com uma trilha de auditoria que comprove qual cliente recebeu qual correção, em qual cronograma e sob a autoridade de quem.
Relatórios e atestados por cliente
Todo cliente deseja receber seu relatório. O formato precisa fazer sentido para o diretor financeiro (CFO) do cliente, e não apenas para o técnico do MSP. Relatórios alinhados às normas de conformidade, como HIPAA, PCI DSS, ISO 27001, NIS2 e Cyber Essentials, precisam ser gerados para cada cliente, sob demanda, sem trabalho manual. Os pacotes de evidências para seguros cibernéticos, que agora estão no centro das discussões sobre subscrição, devem atender aos requisitos específicos da seguradora. Relatórios com marca branca, que colocam a identidade visual do MSP em um documento de conformidade bem elaborado, são o que transformam uma atividade técnica em um serviço justificável e entregável.
Faturamento e embalagem
A TI interna não emite faturas por conta própria — quem faz isso é um MSP. Isso significa que toda atividade de aplicação de patches que consome tempo precisa ser incorporada a uma taxa fixa, gerar um item faturável ou contribuir para o cálculo da margem de lucro. A ferramenta precisa se integrar ao PSA. Os registros de tempo decorrentes de implantações malsucedidas precisam ser direcionados para a fila de tickets correta. As contagens por terminal precisam estar em conformidade com o contrato de licenciamento. Nada disso é glamoroso, mas tudo isso determina se a linha de serviço é lucrativa ou não.
Uma ferramenta que lida com essas cinco dimensões de maneira eficaz é o que diferencia uma plataforma multilocatária de uma ferramenta interna de TI com um seletor de locatários simplesmente acoplado.
O modelo operacional: como um MSP experiente gerencia a aplicação de patches como um serviço
Os MSPs que realizam a aplicação de patches em grande escala não tratam isso como uma série de implantações pontuais. Eles tratam isso como um produto gerenciado, com seu próprio ciclo de vida, seu próprio histórico de registros e seus próprios compromissos de serviço. O modelo possui quatro componentes.
Uma política de referência padronizada
Todos os clientes começam com a mesma política padrão, a menos que haja um motivo específico para se desviar dela. A política padrão é bem definida: patches verificados diariamente, atualizações de segurança aprovadas automaticamente com um período de teste de 48 horas, reinicializações agendadas fora do horário comercial e aplicativos de terceiros atualizados no mesmo ciclo que o sistema operacional. Os desvios são documentados por cliente, com um motivo declarado (conformidade, dependência de aplicativos legados, exigência de controle de mudanças) e uma data de revisão. É essa disciplina que torna a escalabilidade possível. O tratamento personalizado de patches para cada cliente é o que faz com que os MSPs acabem tendo técnicos capazes de dar suporte apenas a determinadas contas e um rastro de documentação que ninguém consegue auditar.
Anéis de implantação, mesmo no âmbito do MSP
As equipes internas de TI utilizam anéis para limitar o alcance dos danos. Os MSPs precisam deles ainda mais, e não menos, porque um patch defeituoso não afeta apenas uma empresa, mas sim dez ou vinte simultaneamente. O padrão maduro utiliza a própria infraestrutura do MSP como Anel 0, um pequeno grupo de clientes confiáveis (geralmente a própria equipe do MSP) como Anel 1, a base mais ampla de clientes de baixo risco como Anel 2 e os clientes de alto risco (setores médico, jurídico, financeiro e de tecnologia operacional na indústria) como o anel final, com tempo de espera adicional. A ferramenta precisa suportar a retenção da implantação entre os anéis com base na telemetria dos anéis anteriores, e não apenas em um temporizador fixo. Confira nossa publicação sobre gerenciamento automatizado de patches para obter mais detalhes sobre a mecânica dos anéis.
Um registro de exceções por escrito
Cada decisão do tipo “esse cliente não pode receber essa correção” é registrada em um registro, com um responsável identificado, um motivo declarado, um controle compensatório e uma data de revisão. Isso pode parecer um ônus. Na verdade, é isso que protege o MSP quando algo dá errado seis meses depois e o cliente pergunta por que o servidor de banco de dados dele não recebeu a atualização. O registro de exceções também gera um sinal operacional útil: clientes com listas de exceções cada vez maiores são aqueles cujo perfil de risco está se alterando, o que deve ser discutido na reunião trimestral de negócios (QBR), em vez de ser um incidente prestes a acontecer.
Comprovantes de conformidade por cliente como resultado contínuo
O programa de patches deve gerar suas próprias evidências de auditoria como um subproduto de sua operação, e não como um exercício de emergência trimestral. O status dos patches por dispositivo, o tempo necessário para a aplicação de patches por nível de gravidade, o registro de exceções e um relatório mapeado de conformidade para o quadro regulatório de cada cliente devem ser gerados sob demanda. É aqui que a diferença entre uma ferramenta que oferece suporte a MSPs e uma ferramenta desenvolvida especificamente para MSPs se torna mais visível. Plataformas de locatário único podem gerar relatórios, mas o trabalho de segmentá-los por cliente, personalizá-los com a marca e organizá-los para um subscritor é manual. Plataformas multilocatárias os geram como resultado natural de sua estrutura.
A questão mais profunda: um programa de patches de MSP que funcione bem se assemelha mais a um processo de fabricação do que a uma atividade de TI. Insumos padronizados, variação controlada, telemetria em todas as etapas, evidências como subproduto. Os técnicos analisam as exceções e as falhas. O sistema cuida do resto.
Ferramentas: O que um MSP precisa e que as ferramentas internas de TI não oferecem
A maioria das ferramentas de gerenciamento de patches foi desenvolvida originalmente para departamentos internos de TI e adaptada posteriormente para MSPs. As limitações arquitetônicas logo se tornam evidentes. Um MSP que esteja avaliando uma plataforma deve testar especificamente os seguintes recursos, pois é nesses pontos que as ferramentas adaptadas para MSPs tendem a apresentar falhas.
Um console multilocatário que seja realmente multilocatário. O técnico deve visualizar todos os clientes em uma única tela, com a capacidade de detalhar o ambiente de qualquer cliente sem precisar sair e entrar novamente, e com acesso baseado em funções que impeça o vazamento de dados entre clientes. A multilocação superficial (um filtro de clientes em um console de locatário único) não resiste a uma carga de trabalho real.
Política por cliente com substituição global. O MSP define uma política padrão no nível global. Cada cliente pode ter substituições no nível do local para as inevitáveis exceções, sem perder a política global como referência. O Datto RMM, por exemplo, oferece suporte a políticas globais de gerenciamento de patches com substituições por local em regras de programação, energia e aprovação, o que constitui o modelo estrutural adequado para o gerenciamento em escala de MSP.
Integração do modo de manutenção com o monitoramento. Quando uma janela de aplicação de patches é aberta, os alertas que a atividade de aplicação de patches irá acionar devem ser suprimidos automaticamente durante essa janela, para que o NOC não responda a reinicializações causadas por falsos positivos e o registro de alertas de cada cliente permaneça limpo. Esse é um pequeno recurso que economiza uma quantidade significativa de trabalho fora do horário comercial.
Cobertura de terminais fora da rede e em roaming. Os clientes de pequenas e médias empresas (PMEs) contam com forças de trabalho híbridas. Os laptops se conectam de casa, de hotéis e de cafeterias. A ferramenta precisa aplicar patches pela internet sem exigir conexão VPN, refazer a tentativa de forma adequada quando os dispositivos voltarem a ficar online e fornecer visibilidade sobre os dispositivos que ficaram de fora da janela de atualização.
Catálogo de aplicativos de terceiros com abrangência relevante para MSPs. A aplicação de patches no sistema operacional é, em grande parte, um problema já resolvido. O diferencial está na profundidade e na atualidade do catálogo de aplicativos de terceiros, pois a maioria das vulnerabilidades CVE exploradas em 2025 estava presente em softwares de terceiros, e não no sistema operacional. Um catálogo de 200 a mais de 300 aplicativos, atualizado poucos dias úteis após o lançamento pelo fornecedor, é o que preenche essa lacuna. A publicação complementar sobre gerenciamento de patches de terceiros aborda mais detalhadamente os aspectos operacionais específicos.
Integração nativa com o PSA. A ferramenta de correção deve alimentar o PSA de forma organizada. As implantações com falha devem gerar tickets na fila correta, com a prioridade adequada e referentes ao contrato correto. Sem essa integração, os técnicos acabam digitando os dados duas vezes, de um sistema para outro, e é aí que a margem de lucro se esgota.
Relatórios com marca branca. Os relatórios que o cliente vê devem ter a aparência do produto do MSP, e não do fornecedor. Logotipo, cores, linguagem — isso pode parecer algo meramente estético. Os clientes interpretam isso como profissionalismo, e é justamente o profissionalismo que justifica o preço.
Integração de dados de vulnerabilidades. A ferramenta de correção deve saber o que consta no catálogo KEV da CISA e apresentar essas informações. Uma plataforma capaz de mostrar “você tem 12 dispositivos executando uma versão do sistema operacional com um CVE que está sendo ativamente explorado; aqui está a correção, implante agora” é fundamentalmente mais útil do que aquela que apenas lista as correções ausentes em ordem alfabética.
Padrões de embalagem e preços
É no modelo comercial que a maioria dos MSPs deixa de lucrar. A aplicação de patches geralmente é incluída na taxa de “ managed services ” sem margem adicional, o que significa que o MSP arca com todo o risco e não obtém nenhum benefício. O modelo maduro separa esses serviços.
A estrutura mais comum é a de preços por terminal, com um modelo em níveis. Um nível básico abrange a aplicação de patches no sistema operacional e em componentes essenciais de terceiros, com relatórios mensais de conformidade. Um nível superior acrescenta cobertura ampliada do catálogo de terceiros, um SLA documentado sobre o tempo de implantação de patches críticos, relatórios de conformidade com marca branca e pacotes trimestrais de evidências de auditoria. Um nível premium para clientes sujeitos a regulamentação inclui SLAs certificados, supervisão por técnico designado e integração com os relatórios de conformidade do cliente (HIPAA, PCI DSS, NIS2). Cada nível corresponde a um preço diferente por terminal, sendo que os níveis mais altos geram margens significativamente maiores.
A estrutura de preços por cliente, somada à de por terminal, é a forma como alguns MSPs lidam com o custo variável. A taxa por terminal cobre a atividade de implantação. Uma taxa mensal fixa por cliente cobre a gestão de políticas, o registro de exceções e os custos indiretos de geração de relatórios, que não variam linearmente com o número de terminais. Um cliente com 10 terminais e outro com 200 terminais consomem quantidades semelhantes de trabalho relacionado a políticas e relatórios; apenas a implantação difere.
A aplicação de patches como uma linha de serviços independente é o modelo mais ambicioso, às vezes conhecido como “Patching-as-a-Service” ou PMaaS. O MSP fornece serviços de aplicação de patches para clientes que utilizam outro MSP para o restante de suas TI, ou para equipes internas de TI que desejam terceirizar especificamente o programa de patches. Esse modelo é mais difícil de vender e operar, mas permite cobrar um preço mais alto e isola o trabalho de aplicação de patches do contrato mais amplo de “ managed services ”.
Em todos os três modelos, a rentabilidade depende da automação. Os MSPs que transformam a aplicação de patches em uma margem lucrativa são aqueles cuja ferramenta executa o trabalho rotineiro sem a supervisão de um técnico, permitindo que a equipe se dedique a lidar com exceções, respostas a emergências e comunicação com o cliente. Os MSPs cujos técnicos passam o tempo clicando para aprovar atualizações a cada “Patch Tuesday” são aqueles que estão perdendo dinheiro nessa linha de serviço e nem percebem.
Conformidade e responsabilidade: a verdadeira garantia
Há anos que a aplicação de patches tem a ver com segurança. Agora, também tem a ver com riscos contratuais.
A mudança no seguro cibernético é o aspecto mais visível. As seguradoras não se contentam mais com declarações do tipo “marcar caixas”. Elas querem evidências: SLAs de patches documentados e cumpridos, cobertura comprovada para aplicativos de terceiros e um processo justificável para patches de emergência. Um MSP capaz de apresentar essas evidências para cada cliente no momento da auditoria está ajudando o cliente a renovar sua apólice. Um MSP que não consiga fazer isso está expondo o cliente ao risco de não renovação e a si mesmo a uma reclamação por erro e omissão (E&O) de tecnologia, caso uma violação seja atribuída a um sistema sem patch coberto pelo MSA.
As estruturas de conformidade que afetam os clientes de pequenas e médias empresas estão se tornando mais específicas quanto à frequência de aplicação de patches. A norma PCI DSS 4.0 exige que patches de segurança críticos sejam aplicados no prazo de um mês após o lançamento. A HIPAA exige a aplicação oportuna de patches como parte de sua Regra de Segurança. A NIS2 já está em vigor em toda a União Europeia e se estende às cadeias de suprimentos do Reino Unido, enquanto a ISO 27001:2022 é agora a referência de fato para clientes que vendem para o setor de compras corporativas. Cada uma delas exige comprovação, não apenas a realização da atividade.
A posição da MSP sobre tudo isso é bem clara: o gerenciamento de patches não é um recurso, é um serviço justificável ao qual o cliente pode recorrer quando seu auditor, seguradora ou conselho de administração perguntar sobre a postura em relação aos riscos cibernéticos. Vender o serviço dessa forma também costuma ter melhor aceitação do que vendê-lo com base em recursos técnicos. Os diretores financeiros se preocupam com as conclusões das auditorias e com os prêmios de seguro. O gerenciamento de patches, quando apresentado da maneira correta, atende a ambos.
Para os MSPs cujos programas ainda apresentam lacunas, nosso blog sobre como elaborar uma política de gerenciamento de patches explica detalhadamente o documento no qual se baseia um programa maduro.
Erros comuns na aplicação de patches por MSPs e como evitá-los
Existem alguns padrões recorrentes entre os MSPs cujos programas de correção parecem adequados no papel, mas geram problemas na prática.
Tratar os clientes como variações da política preferencial do MSP, em vez de partir do perfil de risco de cada cliente. O prazo preferencial de 48 horas para o período piloto estabelecido pelo MSP não é adequado para um cliente do setor de saúde, cuja estrutura de conformidade exige períodos de teste mais longos, nem para um cliente do setor de manufatura, para o qual o custo do tempo de inatividade torna 48 horas um prazo muito curto.
Aprovar patches em massa sem diferenciar servidores de estações de trabalho, de sistemas de Operações (OT) ou de sistemas críticos de linha de negócios. Uma aprovação genérica que instala um patch em um controlador de domínio ao mesmo tempo que em um laptop do departamento de marketing é o que causa interrupções no serviço.
Confiar na métrica de sucesso da implantação sem correlacioná-la com uma verificação de vulnerabilidades. A ferramenta de correção relata o que foi enviado. O verificador relata o que foi efetivamente corrigido. A discrepância entre os dois é onde se encontram as constatações da auditoria.
Deixar que o catálogo de aplicativos de terceiros se torne o gargalo. A aplicação de patches no sistema operacional parece estar resolvida — mas, muitas vezes, a aplicação de patches em aplicativos de terceiros não está. Os MSPs que não auditaram sua cobertura de aplicativos de terceiros nos últimos 12 meses geralmente se surpreendem com o que descobrem.
Tratar a geração de relatórios como algo secundário. Os clientes que renovam contratos com muitas atualizações são aqueles que recebem mensalmente relatórios bem elaborados, com a identidade visual da empresa e alinhados às normas de conformidade. Os clientes que negociam o preço são aqueles que recebem um arquivo CSV.
Quanto às disciplinas fundamentais que evitam a maioria desses padrões, nossa publicação sobre as melhores práticas de gerenciamento de patches aborda os hábitos operacionais que diferenciam os programas que funcionam bem daqueles que enfrentam dificuldades.
Como a Kaseya auxilia os MSPs no gerenciamento de patches
Um programa de patches para MSP que funcione bem precisa de uma plataforma confiável o suficiente para que a equipe confie na automação, com capacidade multilocatária suficiente para que o trabalho seja escalável sem a necessidade de aumento proporcional da equipe e transparente o suficiente para que o cliente possa perceber o valor agregado. Esse é o briefing de projeto no qual a gestão de patches da Datto RMM se baseia, e é aí que o modelo operacional e as ferramentas deixam de ser discussões separadas.
As políticas globais de gerenciamento de patches, com substituições no nível do local em relação à programação, comportamento de reinicialização e regras de aprovação, oferecem aos MSPs a flexibilidade por cliente de que precisam, sem abrir mão de uma linha de base padronizada. O Modo de Manutenção suprime automaticamente os alertas de monitoramento durante as janelas de aplicação de patches, eliminando uma fonte comum de ruído fora do horário comercial. O recurso “Patch Now” lida com as implantações de emergência que não podem esperar pelo ciclo regular. O módulo de Gerenciamento de Software abrange a aplicação de patches de terceiros em mais de 200 aplicativos do Windows e macOS, mantidos atualizados dentro de poucos dias úteis após o lançamento pelo fornecedor. A integração nativa com o PSA da Autotask fecha o ciclo de tickets, faturamento e relatórios de conformidade por cliente.
O Datto RMM também faz parte da Kaseya 365, a assinatura unificada que agrupa RMM, segurança, backup e automação em um único preço por terminal — e é assim que muitos MSPs consolidam o custo operacional de utilizar várias ferramentas licenciadas separadamente.
O trabalho em si não muda muito de ano para ano. O que muda são os riscos envolvidos. As seguradoras de cibersegurança estão atentas. Clientes em setores regulamentados precisam de evidências defensáveis. Os dados sobre ameaças estão se agravando e os prazos para aplicação de patches estão ficando mais curtos. Nada disso justifica tratar a aplicação de patches como uma tarefa rotineira no back office. Tudo isso justifica tratá-la como uma linha de serviços que gera receita, em uma plataforma desenvolvida para a forma como os MSPs operam.
