Segurança Orion

“A segurança através da obscuridade não é muita segurança.”

Paráfase popular do serralheiro americano Alfred Charles Hobbs Em 1851, que facilmente pegou as fechaduras do Palácio de Cristal durante uma exposição em Londres naquele ano. Concordamos plenamente, e é por isso que nossos planos para nosso mecanismo de automação da Oracle Cloud Infrastructure (OCI) são disponível em GitHub.

Segurança da Infraestrutura Orion

Compatível com FIPS 140-3 com tripla criptografia MFA para serviços de encaminhamento de porta reversa (HTTPS/SSH/IPsec). Cinto, suspensórios e estribos!

RBAC modelo, salpicado com ortrus Desafios de OTP/TOTP

Todo o acesso de log-in da conta de infraestrutura requer o fornecimento de credenciais de Autenticação Multifator, incluindo contas do OCI. Não há backdoors para esta política, por design.

Todo o acesso ssh do funcionário a máquinas corporativas requer integração PKI YubiKey com chaves privadas de autorização ECDSA-SHA-2-NISTP-256 armazenadas em slots PKCS11 no Yubikey ou integração direta de Smart Card com Chaves ED25519-sk.

Nenhuma senha fixa armazenada nos discos. Esta automação sem cabeça limits do uso de sudo / RBAC, por uma boa razão. No entanto, temos ferramentas para eliminar o trabalho de resposta a prompts de vários tipos.

Execução em sandbox para builds e scripts CGI

Nós implantamos “nada compartilhado” builds de zona, cujo padrão é zero disponibilidade de rede. Isso significa que as únicas coisas que um cliente pode acessar ou modificar são seus próprios ativos, não aqueles de qualquer outro cliente, ou quaisquer outros caminhos do sistema na própria zona (além de /tmp. Além disso, somente clientes corporativos e corporativos têm acesso à internet durante suas compilações, porque estão usando suas próprias zonas unique Solaris, que podem ser adaptadas exatamente para os requisitos de compilação.

Ditto para scripts CGI, que são totalmente bloqueados em termos de acesso de gravação a qualquer outra coisa que não seja /tmp.

Criptografia de ponta a ponta

• OpenSSL v4+ TLS 1.3 (+FS) AES(256) SHA(256) para conexões HTTPS FIPS 140-3

• OpenSSH v10+ ED25519 FIPS 140-3 com chaves compatíveis pós-quantum KexAlgorithm / NIST para host cruzado lo encaminhamento de porta inversa

• IPsec/IKEv2/PFS AES(256) FIPS 140-2 para VPN entre regiões

• AES(256) para criptografia ZFS

Aspectos do Zero Trust

A premissa básica de arquitetura de confiança zero é evitar projetar sua segurança de rede em torno da fisiologia do clam: duro no exterior, mas macio e solto uma vez que você está dentro. Portanto, não fazemos isso; cada porta de rede privilegiada significativa dentro das várias LANs do Ponto de Presença (POP) só é exposta à interface do dispositivo loopback da máquina bare-metal lo0, e só é significativo no contexto de uma conexão SSH encaminhada por porta (reversa) para ela.

Usamos proxies TCP, não proxies HTTP, e nenhum backends MSA, então o único host que vê seu tráfego web TLS não criptografado é o host que o decriptografa. As mesmas regras se aplicam ao tráfego do Subversion — somente o tráfego direto e de ponta a ponta criptografado TLS para o ponto final de serviço vê seus dados não criptografados na conexão.

Boa sorte com as camadas MSA e camadas de exposição de dados privados com outros fornecedores. O inimigo de “engenharia não funcional” é complexidade. É muito mais fácil fornecer promessas de segurança significativas quando seu produto é um monólito federado em vez de um enorme campo minado MSA, que é outro diferenciador contrário entre a Orion e seu campo de concorrentes.

Esta infraestrutura é totalmente automatizada quando uma região é colocada on-line, mas isso é tudo o que podemos compartilhar publicamente sobre a arquitetura (equilibrando a transparência hobbsiana com o mantra militar). “Lábios soltos afundam navios” mais arte do que ciência). Restante — além de quebrar o antispoofing lo0 dentro do próprio filtro de pacotes do Solaris 11 (BSD), não há meio significativo de obter acesso a esses serviços, mesmo para contas de clientes.

Mesmo que a conta de controle principal da OCI seja comprometida, a confidencialidade e a integridade de todos os ativos do cliente permanecem invioláveis. Tudo o que um black-hat pode fazer é fazer uma bagunça com o site do cliente disponibilidade. Em particular, eles não podem acessar os registros de dados do serviço Subversion. Podemos reconstruir toda a infraestrutura da OCI do zero em 48 a 72 horas depois que o acesso à OCI da má Apple tiver sido encerrado.

Registro, Monitoramento e Auditoria

Incentivamos os clientes da Enterprise a criar uma conta Splunk e forneceremos weblogs quase em tempo real para sua conta em todos os POPs globais que você precisar. Os logs de erro do script CGI do servidor também estão disponíveis para o Splunk.

Monitoramos a disponibilidade do serviço de todos os nossos POPs da OCI em todo o mundo e acionamos eventos de failover de HA (Domínio de Disponibilidade) ou regionais se uma interrupção do servidor durar mais de 30 segundos.

A auditoria da ACL pode ser realizada simplesmente construindo o Subversion HEAD de um site usando o Apache Licenciado Orion SSG e examinando o build resultante no www/.acl em seu diretório de check-out, a qualquer momento que desejar. Normalmente, o processo de construção levará menos de 10 a 15 segundos no hardware moderno.

Subversion Server-Side Commit Hooks também são personalizáveis para suas preocupações de supervisão. Desde um simples mailer de commit até o acesso seguro ao nosso daemon svnpubsub, há várias configurações personalizadas disponíveis.

Segurança do Aplicativo Orion

SSR público é um cheiro

O dinamismo do joelho e o acompanhamento de multidões levaram a riscos catastróficos e custos irracionais para aqueles que criam e operam sistemas on-line. Orion está tomando uma abordagem mais considerada e está desenvolvendo tecnologia de conteúdo estático que borra a distinção tradicional em capacidade de resposta entre sistemas estáticos e dinâmicos. Acho que Joe está em alguma coisa com essa abordagem, e estou ansioso para ver onde ele pode levá-lo.
– Paul Vixie, Internet Pioneer

Separação de preocupações e compensações de engenharia

Em poucas palavras, a forma como todas as outras plataformas wiki funcionam é como um CMS dinâmico, apoiado por SQL. CRUDO aplicativo que torna rápido e fácil modificar o conteúdo, para o qual os resultados devem ser reconstruídos em tempo real (ou a partir de um cache de página da Web) toda vez que alguém precisa visualizar esse conteúdo on-line.

Em (noSQL) Orion, tomamos edição e renderização como duas preocupações separadas que devem ser tratadas por duas pilhas de software independentes; onde muito mais processo, design, validação e gerenciamento de dependência são investidos na interface de edição. Isso é para que possamos limitar o software na pilha de renderização para ser um servidor de arquivos Apache habilitado para SSI barebones com autenticação da web padrão e controles de acesso envolvidos, e otimisticamente esperamos que o conteúdo seja visualizado em uma ordem de magnitude com mais frequência do que é editado.

Consequentemente, a experiência de edição acontece em uma pilha web independente de acesso impossível sem log-in válido, é um pouco menos rápida quando as alterações são carregadas e é muito menos suja; porque validamos e construímos o conteúdo modificado, juntamente com todo o corpus de páginas dependentes, no tempo de edição, não no tempo de renderização. O build acontece em uma Zona de Solaris sandbox protegida e protegida separadamente. Os logs de build são publicados na sessão de edição em tempo real e salvos no controle de versão para posteridade e responsabilidade comercial.

Na realidade, o custo é de alguns segundos a mais de exposição ao maquinário técnico da construção e ao processo de implantação de arquivos estáticos antes de poder ver alterações comprometidas e publicadas no site de produção ao vivo.

E o benefício? Você nunca verá seu site ao vivo ser hackeado novamente por meio de vulnerabilidades de dia zero ou sem patch na pilha de software do servidor web de renderização. Além disso, o site de edição é invulnerável a esforços de hacking anônimos, então você está em uma posição de segurança e arquitetura muito melhor conosco do que com qualquer outro fornecedor de wiki na Terra, independentemente das proteções adicionais implementadas no restante deste documento.

Truque legal, não é?

Mas depende criticamente que o tradeoff seja viável para a experiência do editor. E sem aplicação da nossa patente pendente Gerenciamento de Dependência de Conteúdo Inteligente™ pode não valer o custo para muitas empresas.

Gerenciamento de ACL

O modelo de segurança do Orion é gerenciado centralmente pelas configurações contidas no @path::acl como constrangido em lib/path.pm. Os arquivos de configuração do servidor offshoot são gerados dinamicamente em cada alteração criada.

Se você entender o modelo de segurança do sistema de arquivos POSIX, estará em casa com a Orion’s mod_dav_svn o modelo de autorização e os controles .htaccess do servidor web Apache HTTPd, gerados automaticamente a partir do seu site lib/acl.yml Configuração YAML.

OpenIDC Segurança do SSO

Todos os cookies de sessão OpenID são HttpOnly e Secure sinalizados, de modo que as tentativas de roubo de sessão Javascript são efetivamente neutralizadas pelo Editor On-Line Orion.

Todo o armazenamento de credenciais de cookie é também AES-256 criptografado sob um hash HMAC SHA-1.

Bcrypt para senhas do Subversion

Número ajustável de rodadas (atualmente o padrão é 5). Aqui está um entrada do blog Isso explica a relevância.

Proteções de dados contaminadas

Todos os nossos tempos de execução Perl têm verificações de mancha obrigatórias habilitadas com o sinalizador -T; uma poderosa e exclusiva proteção Perl contra Explorações de Shell Remoto.

Problemas do Wiki

Wiki security involves several factors:

1. Segurança de UI/API

2. Segurança de Middleware/Backend

3. Proteções Transversais do Modelo

4. Segurança Literal da String do Modelo

5. Compatibilidade de ACL do mecanismo de pesquisa

Nós nos aprofundamos nessas questões como eles se relacionam com Orion abaixo.

Editor On-line

O editor on-line suporta uma interface de usuário JSON simplesmente definindo o cabeçalho Accept do seu agente de usuário para preferir o application/json MIME-type, portanto, os controles de segurança são os mesmos para a UI e a API.

Não há IU/API administrativa fora do acesso direto ao Subversion. Em vez disso, oferecemos certas visualizações de dados no mecanismo de pesquisa gratuito que podem ser usadas para construir painéis controlados por acesso dentro do site hospedado.

Caso contrário, cada site é governado pelos arquivos de configuração na base do site lib/ diretório dos materiais de origem no Subversion.

As ACLs do Subversion controlam o acesso de leitura da cópia de trabalho do servidor

Cada recurso de cópia de trabalho disponível por meio da IU é verificado cruzadamente em suas ACLs do Subversion antes de apresentá-las ao usuário. Dessa forma, garantimos que o acesso de leitura a recursos não autorizados seja impedido para os ativos sob controle de versão (também conhecido como tudo).

O acesso de confirmação é controlado diretamente com ACLs do Subversion

Nada pode ser construído e posteriormente visualizado pela rede sem um commit do Subversion autorizado correspondente. O principal problema aqui é controlar quais informações estão disponíveis para as edições confirmadas e construídas de um autor da página wiki.

Se você permitir o pré-processamento de Modelo nas páginas de origem de markdown, deverá estar ciente de como os argumentos de modelo tornam o conteúdo de outros arquivos na árvore disponível como variáveis para a origem da página editada.

Muitas vezes, se configurado para fazê-lo, a página editada pode declarar seus próprios arquivos de dependência nos cabeçalhos da página, o que também é algo para pensar enquanto você pesa conjuntos de recursos contra controles de segurança na Arquitetura de Informações da sua Wiki. Independentemente da sua posição, protegemos o seu site por padrão — incluindo dependências de conteúdo e ssi inclui.

Embora possamos oferecer orientação e suporte para atender às suas necessidades, cabe a você decidir como equilibrar as escalas dos ativos gerenciados da sua organização em uma wiki apoiada pela Orion.

Consulte a seção abaixo em Controles de Injeção de Dependência/ACL para obter mais detalhes, e fazer check-out deste exemplo ao vivo de como ACLs fáceis podem ser configuradas centralmente no lib/acl.yml:

- path: content
  rules:
    "@staff": rw
    "@svnadmin": rw
    "*": r

- path: content/orion
  rules:
    "@staff": rw
    "@svnadmin": rw
    "*": r

- path: lib
  rules:
    "@svnadmin": rw
    "@devops": rw

- path: lib/acl.yaml
  rules:
    "@svnadmin": rw
    "@security": rw

- path: templates
  rules:
    "@svnadmin": rw
    "@frontend": rw

- path: cgi-bin/search.pl
  rules:
    "@svnadmin": rw
    "*":

Os Autores de Conteúdo podem configurar restrições de página no cabeçalhos:

Title: Orion Security
Dependencies: *.md.en api/index.md.en
ACL: @staff=rw, *=r
Keywords: security,infosec,appsec,ipsec,devsecops,it,acl,svnauthz,zerotrust

Como observação lateral, os recursos protegidos não podem ser copiados para uma ramificação por pessoal não autorizado, mesmo sem colocar controles ACL adicionais na criação e modificação da ramificação. Em outras palavras, o sistema suportará a experimentação de filiais sem qualquer controle adicional de sua parte para garantir que os ativos protegidos permaneçam protegidos durante todo o ciclo de vida natural de cada filial.

Criar ACLs do Sistema?

O sistema de compilação é onisciente e onisciente, mas podemos garantir que seus ativos protegidos e construídos sejam visíveis apenas para as equipes que você gerencia e controla nas ACLs do Subversion.

O sistema de compilação revelará a lista de nomes de arquivos que ele criou por meio do IDE do browser em um commit, mas essa lista é baseada apenas no acesso de leitura de um usuário aos recursos dependentes das ações de adição, atualização ou exclusão de conteúdo no commit do usuário.

Controles Transversais do Modelo

Consulte sanitize_relative_path:

sub sanitize_relative_path {
  for (@_ ? @_ : $_) {
    s#^[\\/]+##g;
    s/^\w+://g; #Windows GRR
    s#([\\/])+#$1#g;
    s#/\./#/#g;
    1 while s#[\\/][^\\/]+[\\/]\.\.[\\/]#/#;
    s#^(?:\.\.?[\\/])+##;
  }
}

Este código impõe as regras a seguir nesta seção.

incluir e estender tags

Todos os arquivos de destino estão em uma subpasta do /templates/ e deve ser referenciado como caminhos absolutos com raiz nessa pasta.

tag ssi

Todos os arquivos de destino estão em uma subpasta do /content/ e deve ser referenciado como caminhos absolutos com raiz nessa pasta.

Se o caminho de destino não estiver configurado no @path::patterns com uma configuração correspondente que permite que o caminho de destino em questão seja arquivado ou categorizado, ou que o último autor alterado do arquivo de origem simplesmente não esteja autorizado a exibir o caminho de destino, o ssi operação falhará.

Isso porque ssi o suporte é um pré-requisito para esses conjuntos de recursos, para preservar os permalinks. do alvo do seu site

Filtrar Segurança Envolvendo Expressões Regulares Passadas como Literais de String

Dotiac::DTL urlencodes internamente todos os literais de string antes de expô-los a eval por razões de segurança. Em seguida, deixa-os codificados quando passados como argumentos de filtro, o que é frustrante ao trabalhar com literais de string PCRE.

Nessa situação, nosso garfo de Dotiac::DTL urldecodes a string e faz uma verificação de sanidade em um Safe::reval sandbox antes de expô-los a perlmotor regex. A vantagem é que as literais de string que você digitar em um argumento de filtro suportado serão expostas literalmente a perl — você não precisa escovar duas vezes suas barras traseiras!

Controles de Injeção de Dependência/ACL

Controlado por lib/path.pm importações.

lib/{caminho,view}ACLs do Subversion do .pm

É aconselhável controlar o acesso de gravação a esses recursos, limitando-os a pessoas competentes na base de código e autorizadas a implementar controles de segurança para todo o conjunto de ativos sob controle de versão (também conhecido como tudo).

Também é uma boa ideia incluir o @svnadmin grupo entre aqueles com acesso de leitura-gravação, mas não é estritamente necessário, mesmo que você precise redefinir manualmente suas ACLs do Subversion.

Regras Geradas Dinamicamente via @caminho::acl

O sistema de compilação toma nota de sua lib/path.pm as importações de um (ou ambos) de seed_file_deps() e seed_file_acl(), e levar essa escolha adiante em seu processamento interno de alterações de commit do Subversion que dão origem a uma criação incremental.

Rastreamento de Migração de Conteúdo Controlado

Quando você expõe o histórico completo de controle de versão aos seus usuários, é preciso ter cuidado para preservar os controles de autorização na localização original do material controlado.

Caso contrário, o material poderia ser inadvertidamente exposto a um pesquisador histórico sem as autorizações necessárias.

A lógica de rastreamento move/delete do Orion CMS lida com isso perfeitamente.

Controles Personalizados no uso de seed_file_deps() e seed_file_acl() na lib/path.pm

Além da importação desses símbolos para lib/path.pm, há também uma opção de como e a quais arquivos você deseja aplicá-los durante uma execução de bloco de código walk_content_tree (). Afinal, não é apenas um arquivo de configuração, mas uma base de código, com todos os recursos completos do Turing. Perl Nós viemos a conhecer e apreciar!

Os arquivos .htaccess do site e os arquivos de autorização do Subversion são sincronizados com @path::acl instantaneamente mediante commit

Proteção ACL automática para builds de ramificações efêmeras. Configuração adicional zero necessária.

Controles Integrados do Mecanismo de Pesquisa PCRE

Same situation as the general-purpose UI: ele faz verificações cruzadas no servidor Subversion da IU.

No site ao vivo, o mecanismo de pesquisa fará o mesmo quando você ativar pesquisas de markdown (árvore de origem). Caso contrário, ele executará sub-solicitações httpd para o seu site ao vivo para testar se o usuário está autorizado a acessar esse arquivo ao vivo (supondo que você tenha protegido por senha seu mecanismo de pesquisa para que ele tenha dados do usuário para trabalhar).

Políticas de Segurança de Conteúdo

• Restrições de análise

Google, X e/ou LinkedIn.

• Restrições de Dados

Os dados devem ser fornecidos pelos nossos servidores.

• Restrições de Conteúdo

O conteúdo deve ser entregue de nossos servidores.

• Restrições de Código

Código Javascript deve ser entregue a partir de nossos servidores.

• Restrições de Estilo

CSS deve ser entregue a partir de nossos servidores.

• Restrições de plug-in

Atualmente, apenas em PDF.

Compartilhamento de Recursos entre Origens

• Todos os usuários com uma conta podem consumir UI/APIs de outro lugar usando suas credenciais de log-in.

• Clientes empresariais podem tratar a Orion como um CMS sem cabeça se quiserem criar sua própria interface de usuário a partir do JSON Subversion Porcelana ou Pesquisa JSON APIs.

Dependências de Terceiros

Dependências notavelmente breves e testadas no tempo; cujos principais componentes são abordados no Tecnologia Orion página.

Lista de Materiais (SBOM) de Software Integral Disponível mediante Solicitação

Fale Conosco para mais detalhes.