Este documento detalha o processo de liberação do software NSP.
O processo de liberação do NSP baseia-se nos requisitos do cliente e nas práticas recomendadas seguidas por nossas outras equipes. O objetivo principal desse processo é criar e manter ciclos de versão bem definidos e previsíveis. Esse processo nos permite resolver diversas necessidades dos clientes. Alguns clientes precisam permanecer em uma única versão por um período prolongado, em vez de adotar os recursos de segurança mais recentes.
O NSP é compatível com os seguintes tipos de versões:
- Versão principal:
Uma versão principal, também conhecida como versão de linha de base, é adequada para os clientes que estão sob controle de alterações rígida. Uma versão principal fornece novos recursos e aprimoramentos, e é certificado. Os clientes podem permanecer nesta versão por um período prolongado.
- Versão do recurso:
Uma versão de recurso fornece novos recursos e aprimoramentos. É adequado para os clientes que desejam participar da adoção antecipada de novos recursos.
- Versão de manutenção:
Uma versão de manutenção, também conhecida como versão do atualização, fornece correções de software. Ele é fornecido uma vez a cada dois meses para as versões principais e liberações de recursos.
- Versão do Hotfix:
Uma versão de hotfix fornece correções de software para as versões principais e liberações de recursos. Ele é fornecido apenas com base na necessidade de selecionar os clientes que solicitam correções imediatas e não podem aguardar a liberação de manutenção. Uma versão de hotfix também pode incluir mais de uma correção.
Nota: A engenharia de NSP determina, no momento do planejamento de liberação, se uma versão é um recurso ou uma versão principal. O número da versão para a liberação é selecionado de acordo.
Veja a seguir um exemplo de lançamento para versões do software NSP:
Observe os termos a seguir, usados neste documento, que explicam a política de suporte de software para o NSP:
- Período de fim da vida útil (EoLP):
EoLP é o período dia em que anunciamos a descontinuação da versão do produto até o último dia em que formamos o suporte formal da versão do produto. EoLP é o período entre o fim da vida útil (EoLS) e o fim da vida útil (EoLE).
- EoLS: os dois cenários a seguir são aplicáveis:
- Depois que o EoLS for declarado, não haverá mais liberações de manutenção durante o EoLP. Os hotfixes e o suporte ao conjunto completo de assinaturas são fornecidos pelos próximos 12 meses.
- No caso de lançamentos principais, há um suporte estendido de mais 12 meses (um total de 24 meses após o EoLS).
Durante esse período, não há mais versões de manutenção. O suporte ao conjunto completo de assinaturas e os hotfixes críticos limitados são fornecidos.
- EoLE: nenhum hotfix ou conjunto de assinaturas é fornecido. O software é EoL.
Abaixo encontra-se uma ilustração de um ciclo de vida da versão principal e do recurso:
Abaixo estão listadas as características de uma versão principal em relação ao lançamento de um recurso:
|
Versão principal |
Versão do recurso |
Versões |
O segundo dígito da versão do produto é numerado como ". 1". Por exemplo 9.110.1 ,, 11.1. |
O segundo dígito da versão do produto é numerado como. 2,. 3, etc. Por exemplo, 9.29.310.2 ,,, 10.3. |
Escopo de liberação |
Uma versão principal pode incluir aprimoramentos de software para o seguinte:
- Novos recursos
- atualização de infraestrutura
- Compatibilidade
- Introdução ao novo hardware
- Certificação
|
Uma versão do recurso pode incluir aprimoramentos de software para o seguinte:
- Novos recursos
- atualização de infraestrutura
- Compatibilidade
- Introdução ao novo hardware
|
Linha do tempo |
A versão principal é de cerca de 18 meses. |
A versão do recurso é de cerca de 6 meses até a próxima versão principal. |
Período de suporte |
O período de suporte principal da versão é de 48 meses:
- 24 meses de engenharia e suporte ao Suporte técnico-Sra, hotfixes e conjunto completo de assinaturas
- 24 meses de Suporte técnico
- 24 a 36 meses-sem suporte a Sra, Full Signature Set support e hotfixes
- 37 a 48 meses-sem suporte a Sra, Full Signature Set support e hotfixes críticos limitados
|
O período de suporte da versão do recurso é de 20 meses:
- 8 meses de engenharia e suporte ao Suporte técnico-Sra, hotfixes e conjunto completo de assinaturas
- 12 meses de Suporte técnico-nenhum suporte total para o conjunto de assinaturas da Sra e hotfixes
|
EoLS |
O EoLS é 24 meses após o GA.
Um anúncio de EoL é enviado para indicar essa fase. |
O EoLS é de 8 meses após o GA. Um anúncio de EoL é enviado para indicar essa fase. |
EoLP |
O EoLP é de 24 meses. |
O EoLP é de 12 meses. |
EoLE |
O EoLE é 24 meses após o EoLS. |
O EoLE é de 12 meses após o EoLS. |
Versão de manutenção |
A liberação da manutenção deve ser fornecida uma vez a cada dois meses de acordo com a necessidade, até EoLS. |
A liberação da manutenção deve ser fornecida uma vez a cada dois meses de acordo com a necessidade, até EoLS. |
Hotfixes |
Os hotfixes são fornecidos de acordo com os dois cenários a seguir:
- Depois que o EoLS é declarado, os hotfixes são fornecidos nos próximos 12 meses.
- Para o período restante até o EoLE, hotfixes críticos limitados são fornecidos.
|
Os hotfixes são oferecidos de acordo com a necessidade, até EoLE. |
Conjunto de assinaturas |
As atualizações do conjunto de assinaturas são fornecidas até EoLE. |
As atualizações do conjunto de assinaturas são fornecidas até EoLE. |
Vulnerabilidades correções |
As correções de vulnerabilidades são fornecidas de acordo com a necessidade, até EoLE. |
As correções de vulnerabilidades são fornecidas de acordo com a necessidade, até EoLE.
Importante: O NSP Engineering pode permitir uma exceção em determinados casos em que um esforço significativo é necessário para dar suporte à correção. A aprovação do cabeçalho do Negócios é necessária para exceções. |
Suporte para novo hardware/plataforma |
Qualquer hardware ou plataforma novo NSP é compatível com as versões principais de lançamento ou de recursos, dependendo escopo das alterações envolvidas. |
Certificação |
Cada versão principal é certificada para CC/FIPS/UC APL, etc. As versões de certificação são numeradas como 9.1.15.x , 9.1.17.x9.1.19.x. |
Localização |
A localização da interface do usuário do módulo de relatórios do Manager e da documentação do produto é feita para o lançamento principal e está disponível pela MR1 da versão principal. A interface do usuário e a documentação dos relatórios de Manager de cada versão do recurso são localizadas. A interface do usuário de relatórios do Manager e a documentação geral do produto estão traduzidas nos seguintes idiomas: Japonês, coreano, chinês simplificado e tradicional. |
Perguntas frequentes:
sou um cliente NSP existente. Quando posso esperar a implementação da versão atual do processo de liberação do NSP?
O processo de lançamento do NSP descrito neste documento é em vigor no 4º trimestre de 2017 em diante.
Sou um novo cliente e desejo instalar o NSP. Que versão de ramificação devo usar?
Recomendamos que você instale uma versão do recurso para tirar proveito dos recursos e aprimoramentos mais recentes. No entanto, sua decisão precisa considerar o processo de controle de alterações de sua organização. Se a sua organização aplicar uma política de upgrade estrita ou quiser permanecer em uma única versão de lançamento por um longo período, recomendamos que você use a versão principal.
Estou usando a versão 9.1. principal posso migrar para a versão 9.2 do recurso?Sim. No entanto, depois que uma versão do recurso é adotada, você deve permanecer no caminho da versão do recurso até que a próxima versão principal seja disponibilizada.
Se for necessário voltar para a versão principal anterior, você precisará reconfigurar e iniciar o novamente.
Quais são as opções de upgrade compatíveis entre as versões do recurso e as versões principais?
Os cenários de upgrade compatíveis para o software Sensor e Manager são os seguintes:
- Há suporte para os upgrades da versão principal anterior para a próxima versão principal. Por exemplo, de 8.1 para 9.1 e 9.1 para 10.1.
- Há suporte para os upgrades do lançamento do recurso anterior para a próxima versão do recurso. Por exemplo, se houver versões 9.2 de recursos e 9.3 você estiver atualmente ligado 9.2 , poderá upgrade para 9.3.
- Há suporte para os upgrades das versões anteriores dos dois recursos para a próxima versão principal. Por exemplo, se houver versões 8.2 e 8.3 você puder upgrade de 8.2 e 8.3 ambas para 9.1.
As versões do recurso do Manager são compatíveis com sensores heterogêneos de recursos e versões principais?
Os cenários com suporte são os seguintes:
- A principal versão do Manager suporta sensores heterogêneos para a versão principal imediata anterior e para a versão imediata do recurso anterior. Por exemplo: o 9.1 Manager suporta sensores em execução no 8.19.1 e na versão 8.x mais recente do recurso do software sensor.
- A versão do recurso Manager oferece suporte a sensores heterogêneos para a liberação imediata do recurso anterior e para a versão principal imediata anterior. Por exemplo: o Manager é compatível com os 8.3 sensores em execução 8.3 e 8.1 sensor software.
Nota: O terceiro dígito varia de acordo com diferentes modelos de Sensor. Por exemplo, a série M é 8.1.3.x e a série NS é
8.1.5.x.
As versões do recurso do Central Manager são compatíveis com gerentes heterogêneos de recursos e versões principais?
Os cenários com suporte são os seguintes:
- O Central Manager principal oferece suporte a gerentes heterogêneos para a versão imediata do Manager principal anterior e para o recurso anterior imediato Manager versão. Por exemplo: o 9.1 central Manager suporta gerenciadores em execução no 9.18.1 e no último lançamento de recursos no 8.x software Manager.
- A versão do recurso Central Manager oferece suporte a gerenciadores heterogêneos da versão imediata do recurso anterior e à versão principal imediatamente anterior. Por exemplo: o Central Manager oferece suporte a 8.3 gerenciadores em execução no 8.3 software e 8.1 Manager.
Você fornece uma notificação antecipada quando recomenda que os clientes upgradem o software de Sensor para uma versão mínima recomendada por razões críticas?
Quando anunciamos uma nova imagem de software Sensor para resolver qualquer problema ou vulnerabilidade importante, fornecemos:
- Uma janela de seis meses para os clientes upgrade para a imagem mínima recomendada, se houver uma versão de recurso (por exemplo, de 8.2 para 8.3 ) ou uma versão de manutenção (por exemplo, de 8.3.5.15 para 8.3.5.30 ).
- Uma janela de 12 meses para os clientes upgrade para a imagem mínima recomendada, se houver uma versão principal (por exemplo, de 9.1 até 10.1 ).