Questionário de segurança
As mesmas perguntas chegam em todos os concursos, por isso estão respondidas de antemão e por escrito. Onde não há resposta que possamos sustentar, fica a pergunta e por baixo nada: mais vale uma lacuna do que um número indefensável dois anos depois.
Última revisão: 30 de agosto de 2026
Esta página está paginada para o papel: imprime-se ou guarda-se em PDF a partir do navegador e sai sem menus e sem rodapé.
Em servidores próprios situados na União Europeia, num centro de dados de França operado por Hostinger International Limited. As cópias de segurança permanecem na mesma jurisdição.
Não. Nem o alojamento, nem as cópias, nem o apoio, nem as tarefas de administração são prestados a partir de fora do Espaço Económico Europeu, pelo que não é necessário recorrer a cláusulas contratuais-tipo nem às restantes garantias do capítulo V do RGPD.
É partilhada. Cada tabela de conteúdo leva o identificador da empresa e o isolamento é imposto na camada de dados, não no ecrã: uma consulta não o pode omitir. Existe além disso um teste automático que mete uma empresa rival na mesma base, com conteúdo em cada tabela, e verifica a partir da sessão de um colaborador que não se chega a nada da outra. Corre com o resto da bateria, não uma vez por ano.
Hoje não. O serviço é prestado a partir dos nossos servidores na União Europeia.
Sim. O site e a plataforma são servidos por HTTPS, e o cookie de sessão vai marcado como Secure e HttpOnly: nunca sai por uma ligação sem cifra e o JavaScript não o consegue ler. As páginas não carregam nada de terceiros — nem tipos de letra, nem ícones, nem scripts — pelo que abri-las não provoca um único pedido para fora. O correio de saída vai por TLS na porta 465 ou por STARTTLS na 587, conforme a configuração da caixa.
As palavras-passe não se guardam: guarda-se um derivado obtido com scrypt e um sal diferente por pessoa. Do identificador de sessão existe só o seu hash, pelo que uma extração da tabela não permite fazer-se passar por ninguém. Com o token de SCIM o mesmo: mostra-se uma vez ao criá-lo e na base fica só o seu hash. O segredo de cliente da autenticação única tem de poder voltar a ser lido — é enviado ao fornecedor de identidade em cada troca de código — e por isso vai cifrado com AES-256-GCM, com a chave derivada por HKDF e uma etiqueta própria.
O que está verificado: a base de dados não está exposta à internet e só é acessível a partir do próprio servidor. Os ficheiros carregados ficam no disco, numa pasta por empresa, e não são acessíveis por endereço direto: cada descarregamento volta a verificar a sessão e o pertencer à empresa.
Sem resposta escrita
A cifragem do volume é uma medida da máquina e não da aplicação, pelo que não se afirma aqui. Peçam-no e confirmamos por escrito o que está configurado no servidor.
Sim. As condições do serviço preveem cópias periódicas dentro da União Europeia, na mesma jurisdição que os dados. Não substituem as exportações que a empresa cliente possa fazer por sua conta nem tornam o prestador depositário da única cópia.
Todas as noites, agendadas no próprio servidor. O processo faz duas coisas: uma extração completa da base de dados com pg_dump, no formato próprio do PostgreSQL e comprimido, e um tar.gz com os ficheiros carregados, do qual se excluem as cópias derivadas das imagens porque se voltam a gerar sozinhas. Guardam-se catorze dias, rodam sozinhas e permanecem na mesma jurisdição que os dados.
Sem resposta escrita
O procedimento de restauro e o tempo que demora dão-se por escrito a pedido. É a parte que depende da máquina e do volume de cada dia, e aqui não se publica nenhum número que não se possa sustentar à frente de quem o verifique.
Seis: proprietário, administração, gestor de pessoas, responsável de TI, edição e colaborador. Publicar sem passar por aprovação podem o proprietário, a administração e a edição. Nos ecrãs de administração cada um entra só no que é seu: quem gere pessoas adiciona e desativa pessoas mas não vê a faturação nem o início de sessão único, e quem trata da TI configura o SSO, as chaves de API e os ecrãs de fábrica mas não gere o pessoal. E ninguém pode atribuir um papel com mais permissões do que o seu. As salvaguardas verificam-se no servidor dentro de cada ação e não escondendo o botão: uma ação de servidor responde mesmo que o botão nunca tenha sido desenhado.
A conta bloqueia quinze minutos ao fim de oito tentativas falhadas, e a mensagem de erro não revela se esse endereço existe. Quando não há nenhuma conta para verificar, gasta-se na mesma o tempo de cálculo do hash, para que a resposta não denuncie pela sua rapidez que o endereço não está registado.
Trinta dias sem uso, numa janela que desliza a cada entrada, com um limite absoluto de cento e oitenta dias que não desliza: obriga a identificar-se de novo pelo menos duas vezes por ano. As sessões caducadas apagam-se todas as noites.
Mudar a sua palavra-passe, bloquear a conta a partir da administração e dar-lhe baixa no sistema de pessoal por SCIM. Nos três casos apagam-se todas as suas sessões, pelo que um separador que tenha ficado aberto deixa de valer de imediato.
Própria, não. Quem entra com a conta da sua empresa por autenticação única passa pelas regras de acesso condicional e pelo segundo fator do seu fornecedor de identidade, e aqui não escreve nenhuma palavra-passe. Para quem entra com um código de adesão e um endereço pessoal, isso não se aplica.
Há uma definição que desativa a entrada com palavra-passe para os domínios de correio configurados. Não afeta quem entra com código de acesso sem endereço da empresa: essas contas não têm palavra-passe para desativar, e são metade do quadro numa fábrica ou num armazém.
OpenID Connect, com Microsoft Entra ID, Google Workspace e Okta. Configura-se colando o endereço de descoberta do fornecedor, e daí saem sozinhos os endereços de autorização, de troca e de chaves. Do nosso lado verifica-se a assinatura do token de identidade e que o emissor seja exatamente o que foi pedido.
Não. A autenticação única vai por OpenID Connect e só por aí. É uma decisão e não uma data pendente: SAML é XML assinado, verificar bem essa assinatura exige canonicalização XML, e é daí que saíram quase todos os contornos de autenticação da última década. Se o vosso caderno de encargos exige SAML por escrito, convém dizê-lo antes de avançar.
Sim, SCIM 2.0 em /scim/v2/Users. Declara-se exatamente o que está implementado: filtro por userName e externalId, paginação e modificação parcial com PATCH. Não há operações em lote, nem ordenação, nem etag, nem mudança de palavra-passe por SCIM, e nada disso se declara de propósito: declarar mais do que se faz leva a sincronização a saltar pessoas a acreditar que não.
A conta é desativada, deixa de poder entrar e as sessões abertas são fechadas. Não é apagada: apagá-la levaria consigo as suas publicações e os seus comentários, e um quadro de avisos com buracos é pior do que um quadro com o nome de alguém que já saiu. Há uma definição para anonimizar em vez de desativar. Um DELETE de SCIM também desativa.
Com um token de portador que a própria empresa gera em Administração › Identidade corporativa. Mostra-se uma vez e não se pode voltar a ver: na base fica só o seu hash. Se se perder, gera-se outro e o anterior deixa de valer.
Sim. Cada entrada guarda a empresa, quem agiu, a ação, a entidade afetada, o endereço IP e a data. Cobre entradas e saídas de pessoas, mudanças de perfil, convites criados e revogados, publicações aprovadas e rejeitadas, documentos carregados e apagados, confirmações de leitura, mudanças de palavra-passe, a configuração e a ativação da autenticação única e do SCIM, e a ativação e a desativação de módulos.
Não. É a diferença face ao registo de atividade do dia a dia, que caduca: o rasto de auditoria do que é sensível fica.
Hoje consulta-se a pedido. Ainda não há um ecrã que o mostre nem exportação para um ficheiro.
Só se a empresa contratar o módulo Acessos e atividade. Nesse caso guardam-se os aparelhos a partir dos quais cada pessoa entra e a secção visitada — /comunidades, não /comunidades/fabrica-de-getafe — e nunca o conteúdo do que se lê ou se escreve. Apaga-se sozinho ao fim de noventa dias. Cada pessoa vê os seus próprios aparelhos no seu perfil, não apenas quem administra: um controlo que o quadro de pessoal não pode olhar é vigilância, e um que pode é segurança.
Hostinger International Limited, como fornecedor da infraestrutura onde estão alojados os servidores: atua como subcontratante, tem assinado o contrato correspondente e não acede ao conteúdo. E os consultores externos de contabilidade, fiscalidade e apoio jurídico, limitados aos dados de faturação e sujeitos a sigilo profissional. Qualquer mudança é comunicada com antecedência suficiente para que a empresa cliente se possa opor.
Nenhuma analítica, nenhuma publicidade, nenhuma gestão de campanhas e nenhum componente de redes sociais. Os tipos de letra e os restantes recursos são servidos a partir do nosso servidor. Para fora saem duas coisas e apenas duas: o correio, pelo servidor de envio que se configure; e os avisos do navegador, se forem ativados, que passam pelo serviço de push do navegador de cada pessoa assinados com chaves VAPID segundo o RFC 8292.
Não. Nem com as publicações, nem com os comentários, nem com as respostas dos inquéritos, nem com os documentos. A ferramenta não tem funções de inteligência artificial, por isso também não tem por onde mandar o vosso conteúdo para lado nenhum.
Enquanto o contrato estiver em vigor. Dentro disso há prazos que se aplicam sozinhos todas as noites: a atividade apaga-se ao fim de noventa dias; os avisos lidos, aos noventa; os avisos por ler, aos cento e oitenta; as mensagens do formulário de contacto, ao fim de um ano; e as sessões e os convites caducados, assim que caducam. Os registos do servidor guardam-se noventa dias.
A empresa dispõe de trinta dias de calendário de acesso para exportar a sua informação. Passado esse prazo, os dados e os ficheiros são suprimidos de forma definitiva num máximo de trinta dias adicionais, cópias de segurança incluídas, com a única exceção do que tenha de ser conservado por obrigação legal, que se limita aos dados de faturação.
Os documentos e os ficheiros descarregam-se a partir da própria ferramenta. Uma extração completa de publicações, pessoas e respostas pede-se e entrega-se. Hoje não há um botão para exportar tudo: está no plano de trabalho, sem data comprometida.
A empresa cliente é a responsável pelo tratamento dos dados do seu quadro de pessoal; nós somos subcontratantes. O contrato de subcontratação está publicado dentro da política de privacidade, com as obrigações do artigo 28 do RGPD uma a uma.
Não foi designado, por não se verificar nenhum dos três casos do artigo 37 do RGPD: nem autoridade pública, nem controlo sistemático em grande escala, nem categorias especiais de dados em grande escala.
Sim. Entre as obrigações assumidas como subcontratantes está pôr à disposição do responsável a informação necessária para demonstrar o cumprimento e permitir auditorias, incluindo inspeções, com pré-aviso razoável.
A empresa cliente, que é a responsável pelo tratamento, sem demora indevida e com a informação de que precise para cumprir as suas próprias obrigações de notificação junto da autoridade de controlo e, quando aplicável, junto das pessoas afetadas. É uma obrigação escrita no contrato de subcontratação.
Sem resposta escrita
O prazo concreto em horas desde a deteção não está comprometido por escrito. Se o vosso caderno de encargos exige um número, acorda-se no contrato antes de assinar e não se dá aqui por suposto.
Não. As condições dizem que o serviço é prestado com diligência razoável e que se procura a disponibilidade contínua, mas não se compromete um valor garantido, porque não se mede nem se compensa. Se o vosso caderno de encargos exige um acordo de nível de serviço com penalizações, hoje não o cumprimos.
Mandem-na e respondemos por escrito. As que se repetem acabam nesta página, que é para isso que serve.
info@blastack.com