Esse documento é direcionado aos clientes que possuam contrato de licenciamento de uso das plataformas tecnológicas Orquestra BPMS 4, Orquestra ECM 3 e Zeev, exclusivamente hospedados na nuvem da SML (licenciamento Cloud / SaaS). Ambientes on premises podem aplicar características específicas dos ambientes onde estão instalados.
Ciclo de Vida do Desenvolvimento Seguro, ou SDL (do inglês Security Development Lifecycle), é um processo que consiste na inserção de várias atividades e produtos relacionados a segurança na fase de desenvolvimento de software, como modelagem de ameaças, análise estática do código com uso de ferramentas, revisão de código, testes de segurança direcionados e revisão final de segurança, minimizando o surgimento de vulnerabilidades.
O processo de desenvolvimento ainda considera a execução de testes periódicos realizados para avaliar e garantir que as aplicações atendem aos padrões de segurança bem como testes contínuos de análise de vulnerabilidade.
| Etapa | Descrição |
|---|---|
| Treinamento de segurança | Os membros da equipe de desenvolvimento de produtos da SML realizam treinamento apropriado e periódico para se manterem informados sobre os fundamentos básicos de segurança e sobre as tendências de segurança e de privacidade. Os treinamentos incluem Design de Segurança, Modelagem de Ameaças, Codificação de segurança, Testes de segurança e Privacidade. |
| Requisitos | A análise de requisitos de segurança e de privacidade é realizada no primeiro esboço da especificação de nova funcionalidade de produto ou modificação de funcionalidade existente, e inclui a especificação dos requisitos de segurança mínimos. As SRAS (Avaliações de riscos de segurança) e as PRAS (Avaliações de riscos de privacidade) são processos obrigatórios que identificam os aspectos funcionais do software que requerem uma análise profunda. |
| Design | As atividades de Design incluem a criação das especificações de design de segurança e de privacidade, a revisão da especificação e a especificação dos requisitos de design criptográficos mínimos. As especificações de design descrevem os recursos de segurança e de privacidade que serão expostos diretamente para o usuário, tais como aqueles que requerem a autenticação do usuário para acessar dados específicos ou conteúdos do usuário antes do uso de um recurso de privacidade de alto risco. A modelagem de ameaças é realizada em ambientes onde há um risco de segurança significativo. |
| Implementação | As equipes de produto utilizam lista de ferramentas aprovadas e suas verificações de segurança associadas, como as opções e os avisos de compilador/vinculador. As equipes de produto realizam análises estáticas periódicas de código-fonte. A análise estática do código-fonte fornece uma capacidade escalável de revisão de código de segurança e ajuda a assegurar que as políticas de codificação seguras estejam sendo seguidas. Além da análise estática, todos os códigos fontes passam por análise de code review manual por membros especialistas de produtos. |
| Verificação | A verificação inclui diversos atividades relacionadas a garantir que o software desenvolvido se comporta conforme o planejado e conforme padrões de segurança exigidos e especificados. As atividades de verificação incluem QA - Quality Assurance de software, englobando testes automatizados unitários, de integração, de carga e de segurança, além de testes manuais por equipe especializada. Os ambientes de teste e staging são separados de maneira lógica e física dos ambientes de produção, e nenhum dado de clientes é utilizado nesses ambientes e nas etapas de verificação. |
| Liberação | A etapa de Liberação inclui montagem de plano de resposta de possíveis incidentes pós-liberação, incluindo plano de rollback emergencial, se necessário. Testes funcionais e de segurança finais são executados. O release final é gerado através de ferramenta de Compilação Contínua, e o plano de rollout para ambientes produtivos é estabelecido. |
| Vulnerabilidade | Tratamento |
|---|---|
| Injection | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Broken Authentication | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Sensitive Data Exposure | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| XML External Entities (XXE) | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Broken Access Control | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Security Misconfiguration | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Cross-Site Scripting (XSS) | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Insecure Deserialization | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Using Components with Known Vulnerabilities | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| InsufficientLogging&Monitoring | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Cross-Site Request Forgery (CSRF) | São implementados diversos métodos e ferramentas para mitigiar e eliminar esse risco. Ele também é pauta de consideração no Processo de Desenvolvimento e Melhoría Contínua de Software. |
| Característica | Descrição |
|---|---|
| Transmissão segura | Todos os processos de transmissão de credenciais são criptografados utilizando padrão de mercado HTTPS. |
| Tipos de autenticação | Os produtos da SML suportam autenticação interna da aplicação, autenticação integrada com Active Directory / LDAP do cliente e/ou SSO com login autenticado junto aos provedores Google e Microsoft / Office 365 |
| Armazenamento de senhas | A SML utiliza as melhores práticas de segurança, nunca armazenando senhas de usuários, seja criptografadas ou não |
| Algoritmo lento | Os produtos da SML utilizam um algoritmo propositadamente lento para a autenticação de usuários, inviabilizando ataques de force brute. |
| Políticas de gestão de senhas |
No caso de utilização do provedor de autenticação interna, a senha mínima requerida contém um número mínimo de caracteres e números. Nesse cenário, também, o cliente pode definir políticas diversas de gestão de senhas, tais como:
|
| Acesso a senhas | No caso de utilização do provedor de autenticação interna, nenhum outro usuário, nem mesmo superadministrador da ferramenta, tem acesso ou pode definir senha para um usuário. Somente o próprio usuário tem acesso a definição de sua senha. |
| Bloqueio de contas | No caso de utilização do provedor de autenticação interna, tentativas sequenciais e inválidas de acesso ao sistema irão bloquear a conta do usuário temporariamente. |
| Bloqueio de acesso via LDAP ou SSO | No caso de utilização de provedor Active Directory / LDAP ou SSO / Google / Microsoft, no momento do bloqueio ou inativação do usuário no provedor de autenticação seu acesso é automaticamente bloqueado no produto SML. |
| Autenticação de APIs | Todas as conexões com APIs do sistema precisam ser autenticadas, utilizadando padrão de indústria JWT |
| Característica | Descrição |
|---|---|
| Grupos de manutenção | O acesso a funções e módulos específicos do sistema é definido pela alocação de grupos de manutenção a usuários. Os grupos de manutenção possuem granularidade de operações dentro de um determinado módulo. |
| Permissões de conteúdo | Além do permissionamento de acesso a módulo, podem existir diversos níveis de personalização de permissões de acesso a informações dentro de um mesmo módulo. Por exemplo, mesmo que dois usuários tenham acesso a uma mesma biblioteca de documentos, permissões personalizadas granularizadas podem fazer com que tenham acesso a um rol de documentos diferentes. |
| Autorização de APIs | Todas as requisições a APIs do sistema passam pelos mesmos critérios de autorização de operações realizadas a nível de interface da aplicação. |
| Característica | Descrição |
|---|---|
| Trilha de auditoria | Os produtos da SML possuem trilha de auditoria que inclui identificação de data, hora, nome do usuário, endereço IP e apontamento para o registro criado, modificado ou excluído. |
Os servidores da SML estão atualmente hospedados nos data centers da Ascenty que é líder na América Latina em Infraestrutura de Data Centers. Todas as unidades de seus Data Centers oferecem padrão internacional Tier III e estão interligadas por uma extensa rede própria de fibra óptica, garantindo conectividade de alta capacidade entre seus sites e os principais cloud providers do mundo.
| Data center | Certificações |
|---|---|
| Principal – Ascenty Campinas |
|
| DR – Ascenty São Paulo III |
|
| Característica | Descrição |
|---|---|
| Anti-DDos | Camada de segurança é garantida por sofisticados algoritmos de análise, que detectam e identificam o lado do tráfego malicioso de forma granular. Desta forma, a solução analisa o tráfego de maneira inteligente, sem prejudicar a experiência de nossos usuários ou a performance da rede, fazendo com que somente as conexões validas trafeguem até o ambiente e aplicações. |
| Firewall de Borda |
Segunda camada de segurança garantindo que somente conexões válidas tenham acesso ao ambiente:
|
| Anti-malware | Terceira camada de segurança atuando diretamente no nível do sistema operacional que tem como principal objetivo bloquear qualquer ameaça virtual. |
| Certificado SSL | SSL é a abreviação de Secure Socket Layer, um padrão global em tecnologia de segurança. Através dele é estabelecido uma conexão criptografada entre o servidor web e o seu navegador para garantir que os dados sejam transmitidos de forma segura e sigilosa. Esse nível de segurança está presente em todos os ambientes do Cloud da SML Brasil. |
| Monitoramento 24x7 | A SML possui poderosa plataforma de monitoramento automatizado para garantir que todos os serviços essenciais estejam em pleno funcionamento. Caso seja identificado qualquer instabilidade ou paralisação de algum destes serviços, uma equipe de profissionais será alertada imediatamente. |
| Cloud Back-up | São realizados back-ups diários de forma totalmente automatizada e os dados são retidos por 7 dias corridos. |
| VPN Site to Site | VPN é a sigla para Virtual Private Network, tendo a função de garantir o tráfego de dados de forma segura e sigilosa entre dois pontos. Esta ponte virtual une redes em vários locais, para conectá-las através da Internet, e manter uma comunicação segura e privada entre essas redes. É um serviço opcional, contratado a parte. |
O objetivo do Disaster Recovery é minimizar o tempo de inatividade de um serviço causado por circunstâncias emergenciais, que venham inviabilizar o funcionamento dos sistemas e/ou hardwares que sustentam uma aplicação Cloud.
De forma geral, a solução de Disaster Recovery mantém replicada toda a infraestrutura digital (tais como softwares, aplicações, dados), em data centers com no mínimo 100km de distância entre eles. Essa distância física é proposital, de modo a mitigar problemas em hardware, catástrofes naturais, ou problemas que afetem uma determinada região (como falta de energia, de conexão) ou mesmo por consequência de ataque de hackers.
Disaster Recovery depende de um Plano – Disaster Recovery Plan – que deve ser elaborado caso a caso para atender às exigências específicas, como por exemplo: garantir replicação em pouquíssimos segundos de RPO (Recovery Point Objective).
*Serviço opcional e contratado à parte.