Após uma análise cuidadosa, tomamos a decisão de fechar o acesso de novos clientes à experiência autogerenciada de modernização de AWS mainframe, a partir de 30 de junho de 2026. Os clientes existentes podem continuar usando o serviço normalmente.AWS continua investindo em melhorias de segurança e disponibilidade para a experiência autogerenciada de modernização de AWS mainframe, mas não planejamos introduzir novos recursos. Para obter mais informações, consulte Alteração na disponibilidade AWS da modernização do mainframe.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

AWS O Mainframe Modernization Service (experiência em Managed Runtime Environment) não está mais aberto a novos clientes. Para recursos semelhantes ao AWS Mainframe Modernization Service (experiência em Managed Runtime Environment), explore o AWS Mainframe Modernization Service (Experience). Self-Managed Os clientes atuais podem continuar usando o serviço normalmente. Para obter mais informações, consulte Alteração na disponibilidade AWS da modernização do mainframe.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

AWS Transforme os segredos do Runtime para mainframe

Algumas das configurações de recursos que contêm credenciais podem ser ainda mais protegidas usando segredos da AWS . A ideia é armazenar dados críticos em um AWS segredo e ter uma referência ao segredo na configuração YAML para que o conteúdo secreto seja coletado rapidamente na startup do Apache Tomcat.

Segredos para Aurora

A configuração do banco de dados do Aurora (para JICSBlusam, banco de dados do cliente etc.) usará o segredo do banco de dados integrado, que preencherá automaticamente todos os campos relevantes do banco de dados correspondente.

Outros segredos

Outros segredos são para recursos que têm uma única senha (principalmente caches redis protegidos por senha). Nesse caso, o outro tipo de segredo deve ser usado.

Referências YAML a segredos

O application-main.yml pode consultar o ARN de vários recursos:

Banco de dados JICS

Credenciais do banco de dados JICS com spring.aws.jics.db.secret

spring:
   aws:
     jics:
       db:
         dbname: jics
         secret: arn:aws:secretsmanager:XXXX

Chaves secretas do banco de dados JICS compatíveis:

Banco de dados da Blusam

Blusamcredenciais de banco de dados com spring.aws.client.bluesam.db.secret

spring:
   aws:
     client:
       bluesam:
         db:
           dbname: bluesam 
           secret: arn:aws:secretsmanager:XXXX

Chaves secretas Blusam de banco de dados suportadas:

Banco de dados de clientes

O cliente application-profile.yml pode referenciar o ARN secreto do banco de dados do cliente. Isso requer uma propriedade adicional para listar os nomes de fontes de dados spring.aws.client.datasources.names. Para cada nome de fonte de dados, ds_name especifique o ARN secreto na seguinte propriedade: spring.aws.client.datasources.ds_name.secret. Exemplo:

spring:
   aws:
     client:
       datasources:
         names: primary,host 
         primary:
           secret: arn:aws:secretsmanager:XXXX
         host:
           dbname: hostdb 
           secret: arn:aws:secretsmanager:XXXX

nomes: primary,host:

Um exemplo com duas fontes de dados de clientes chamadas primary e host, cada uma com seu banco de dados e credenciais.

nome do banco de dados: hostdb:

Neste exemplo, o nome do banco de dados “host” não está no segredo e é fornecido aqui, enquanto que para o banco de dados “primário” ele está no segredo.

Chaves secretas do banco de dados do cliente compatíveis:

Banco de dados de utilitários PGM

O application-utility-pgm.yml pode consultar o ARN de segredo para vários recursos.

Tipo: string

Nome totalmente qualificado da implementação do grupo de conexões a ser usado.

Tipo: string

Padrão: com.zaxxer.hikari.HikariDataSource

Lista de nomes de fontes de dados.

Tipo: string

O nome do host.

Tipo: string

ARN do segredo do banco de dados do host.

Tipo: string

Nome totalmente qualificado da implementação do grupo de conexões a ser usado.

Tipo: string

Padrão: com.zaxxer.hikari.HikariDataSource

Para um segredo de várias fontes de dados:

spring:
   aws:
     client:
       primary:
         secret: arn:aws:secretsmanager:XXXX
         type: dataSourceType
       utility:
         pgm:
           datasources:
             names: dsname1,dsname2,dsname3
               dsname1:
                 dbname: dbname1
                 secret: arn:aws:secretsmanager:XXXX
                 type: dataSourceType
               dsname2:
                 dbname: dbname2
                 secret: arn:aws:secretsmanager:XXXX
                 type: dataSourceType
               dsname3:
                 dbname: dbname3
                 secret: arn:aws:secretsmanager:XXXX
                 type: dataSourceType

Nenhuma chave secreta compatível com XA.

Em relação a postgres, somente o valor da chave secreta sslMode (disable/allow/prefer/require/verify-ca/verify-full) e a propriedade spring.aws.rds.ssl.cert-path YAML possibilitam a conexão com SSL.

Chaves secretas compatíveis com XA.

Se o banco de dados do cliente estiver usando XA, as subpropriedades xa são aceitas por meio de valores do segredo.

No entanto, para outras propriedades xa (por exemplo, maxPoolSize ou driverType), a chave YAML normal spring.jta.atomikos.datasource.XXXX.unique-resource-name ainda deve ser fornecida.

O valor do segredo substitui as propriedades YAML.

Superadmin BAC e JAC padrão

Também é possível configurar application-main.yml para recuperar o nome de usuário e a senha do usuário superadministrador padrão no segredo do AWS Secrets Manager especificando o ARN. O exemplo a seguir mostra como declarar esse segredo em um arquivo YAML.

spring:
   aws:
     client:
       defaultSuperAdmin:
         secret: arn:aws:secretsmanager:XXXX

Chaves secretas padrão do banco de dados superadmin aceitas:

OAuth2

Você também pode configurar `application-main.yml` para recuperar o OAuth2 segredo do cliente especificando o provedor e o ARN. AWS Secrets Manager O valor padrão para a propriedade do provedor é Amazon Cognito. Veja a seguir um exemplo de configuração para o OAuth2 provedor Keycloak:

spring:
   aws:
     client:
       provider: keycloak
       keycloak:
         secret: arn:aws:secretsmanager:XXXX

Neste exemplo, o segredo do cliente do OAuth2 provedor Keycloak é recuperado do ARN especificado no AWS Secrets Manager. Essa configuração comporta vários provedores resolvendo dinamicamente o nome do provedor e o ARN do segredo correspondente.

Chaves OAuth2 secretas suportadas:

Gerenciador de segredos para caches do Redis

O arquivo application-main.yml pode fazer referência ao ARN do segredo para caches do Redis. Os aceitos são:

O exemplo a seguir mostra como declarar esses segredos em um arquivo YAML.

spring:
   aws:
     client:
       gapwalk:
         redis:
           secret: arn:aws:secretsmanager:XXXX
       bluesam:
         locks:
           redis:
             secret: arn:aws:secretsmanager:XXXX
         redis:
           secret: arn:aws:secretsmanager:XXXX
       dataset:
         catalog:
           redis:
             secret: arn:aws:secretsmanager:XXXX
       jics:
         redis:
           secret: arn:aws:secretsmanager:XXXX
       session:
         tracker:
           redis:
             secret: arn:aws:secretsmanager:XXXX
       jics:
         queues:
           ts:
             redis:
               secret: arn:aws:secretsmanager:XXXX
       jcl:
         checkpoint:
           redis:
             secret: arn:aws:secretsmanager:XXXX
       gapwalk:
         files:
           locks:
             redis:
               secret: arn:aws:secretsmanager:XXXX
       blu4iv:
         locks:
           redis:
             secret: arn:aws:secretsmanager:XXXX

Chaves secretas do Redis aceitas:

Gerenciador de segredos para configurações de senha SSL.

O arquivo application-main.yml pode fazer referência ao ARN do segredo para configurações de senha SSL. Os seguintes itens não são aceitos.

O exemplo a seguir mostra como declarar esses segredos em um arquivo YAML.

spring:
   aws:
     client:
       ssl:
         secret: arn:aws:secretsmanager:XXXX

Gerenciador de segredos para configurações de senha do IBM MQ.

O application-main.yml arquivo pode referenciar o ARN secreto para as configurações do IBM MQ. Os seguintes itens não são aceitos.

O exemplo a seguir mostra como declarar esses segredos em um arquivo YAML.

mq.queues.jmsMQQueueManagers[0].secret: Secret-0-ARN 
mq.queues.jmsMQQueueManagers[1].secret: Secret-1-ARN 

Para obter informações sobre segredos ARNs, consulte O que há em um segredo do Secrets Manager?

As propriedades definidas no segredo substituirão seus valores correspondentes na configuração jmsMQ YAML.

Se queueManager estiver definido no segredo, ele substituirá o mq.queues.jmsMQQueueManagers[N].jmsMQQueueManager valor no arquivo YAML.

Banco de dados JHDB

O application-jhdb.yml arquivo do cliente pode referenciar o segredo ARNs para bancos de dados de metadados JHDB. Cada conexão de banco de dados requer um nome exclusivo e um ARN secreto correspondente contendo as credenciais de conexão. Os nomes dos bancos de dados são definidos em uma lista separada por vírgulas, com o segredo individual ARNs mapeado para cada nome do banco de dados.

spring:
   aws:
     jhdb:
       cnxs:
         datasources:
           names: DBD1,DBD2
           DBD1:  
             secret: arn:aws:secretsmanager:XXXX
           DBD2:
             secret: arn:aws:secretsmanager:XXXX

Chaves secretas do banco de dados do cliente compatíveis: