Sécurité d'Orion

“La sécurité par l’obscurité n’est pas du tout une sécurité.”

Paraphrase populaire de serrurier américain Alfred Charles Hobbs En 1851, il choisit facilement les serrures du Crystal Palace lors d’une exposition londonienne cette année-là. Nous sommes tout à fait d’accord. C’est pourquoi nos plans pour notre moteur d’automatisation Oracle Cloud Infrastructure (OCI) sont disponible sur GitHub.

Sécurité de l’infrastructure Orion

Fonctionnalité FIPS 140-3 avec triple chiffrement MFA pour les services transférés vers le port inverse (HTTPS/SSH/IPsec). Ceinture, bretelles et étriers !

RBAC modèle, poivré avec orthèse Défis liés aux mots de passe à usage unique/TPO

Tous les accès de connexion au compte d’infrastructure nécessitent de fournir des informations d’identification d’authentification à plusieurs facteurs, y compris les comptes OCI. Il n’y a pas de backdoors à cette politique, par conception.

L’accès SSH de tous les employés aux machines d’entreprise nécessite l’intégration PKI YubiKey avec les clés privées d’autorisation ECDSA-SHA-2-NISTP-256 stockées dans les emplacements PKCS11 sur la Yubikey, ou l’intégration directe de la carte à puce avec les clés ED25519-sk.

Aucun mot de passe fixe stocké sur les disques. Cette limite l’automatisation sans tête de l’utilisation de sudo / RBAC, pour une bonne raison. Cependant, nous avons outils pour éliminer le travail consistant à répondre à des invites de divers types.

Exécution en bac à sable pour les builds et les scripts CGI

Nous déployons “partage-rien” builds de zone, avec une disponibilité réseau nulle par défaut. Cela signifie que les seules choses auxquelles un build client peut accéder ou modifier sont ses propres actifs, pas ceux d’un autre client, ou tout autre chemin système sur la zone elle-même (en plus de /tmp. En outre, seuls les clients professionnels et professionnels disposent d’un accès Internet pendant leurs builds, car ils utilisent leurs propres zones unique Solaris qui peuvent être adaptées exactement à leurs exigences de build.

Ditto pour les scripts CGI, qui sont entièrement verrouillés en termes d’accès en écriture à tout autre chose que /tmp.

Chiffrement de bout en bout

• OpenSSL v4+ TLS 1.3 (+FS) AES(256) SHA(256) pour les connexions HTTPS FIPS 140-3

• OpenSSH v10+ ED25519 FIPS 140-3 avec clés conformes à Post-Quantum KexAlgorithm / NIST pour les hôtes croisés lo rétro-transfert de port

• IPsec/IKEv2/PFS AES(256) FIPS 140-2 pour VPN interrégional

• AES(256) pour le chiffrement ZFS

Aspects de confiance zéro

La prémisse de base de architecture sans confiance est d’éviter de concevoir votre sécurité réseau autour de la physiologie de la palourde : dur à l’extérieur, mais doux et lâche une fois que vous êtes dans. Donc, nous ne faisons pas cela ; chaque port réseau privilégié significatif à l’intérieur des différents LAN du point de présence (POP) n’est exposé qu’à l’interface de périphérique loopback de la machine bare metal lo0, et n’a de sens que dans le contexte d’une connexion SSH (inverse) transmise au port **.

Nous utilisons des proxies TCP, pas des proxies HTTP, et aucun back-end MSA, donc le seul hôte qui voit votre trafic Web TLS non chiffré est l’hôte qui le déchiffre. Les mêmes règles s’appliquent au trafic Subversion — seul le trafic crypté TLS direct et de bout en bout vers l’ adresse de service voit vos données non cryptées sur le réseau.

Bonne chance avec les couches MSA et couches d’exposition de données privées avec d’autres fournisseurs. L’ennemi de “ingénierie non fonctionnelle” est la complexité. Il est beaucoup plus facile de fournir des promesses de sécurité significatives lorsque votre produit est un monolithe fédéré au lieu d’un énorme champ de mines MSA, ce qui est un autre différenciateur contradictoire entre Orion et son domaine de concurrents.

Cette infra est entièrement automatisée une fois qu’une région est mise en ligne, mais c’est tout ce que nous pouvons partager publiquement sur l’architecture (équilibrer la transparence Hobbsian avec le mantra militaire) “bateaux d’évier de lèvres lâches” plus d’art que de science). Soyez assuré — au-delà de briser l’antispoofing lo0 protection dans le filtre de paquets d’ Solaris 11 (BSD) lui-même, il n’y a pas de moyen significatif d’accéder à ces services, même pour les comptes client.

Même si le compte de contrôle OCI maître est compromis, la confidentialité et l’ intégrité de tous les actifs client restent inchangées. Tout ce qu’un black-hat peut faire est de perturber la disponibilité du site Web du client. En particulier, ils ne peuvent pas accéder aux enregistrements de données du service Subversion. Nous pouvons reconstruire l’ensemble de l’infrastructure OCI de toutes pièces en 48 à 72 heures une fois l’accès OCI de la mauvaise pomme terminé.

Journalisation, surveillance et audit

Nous encourageons les entreprises clientes à créer un compte Splunk, et nous livrerons des weblogs en temps quasi réel à votre compte à partir de tous les POP mondiaux dont vous avez besoin. Les journaux d’erreurs de vos scripts CGI côté serveur sont également mis à la disposition de Splunk.

Nous surveillons la disponibilité du service à partir de tous nos POP OCI à l’échelle mondiale et déclenchons des événements de basculement de haute disponibilité (domaine de disponibilité) ou régionaux si une panne de serveur dure plus de 30 secondes.

L’audit ACL peut être effectué en construisant simplement la tête Subversion d’un site Web à l’aide de la licence Apache. Orion SSG le script et l’examen du paramétrage résultant dans la www/.acl fichier dans votre répertoire de paiement, à tout moment. Normalement, le processus de construction prendra moins de 10 à 15 secondes sur le matériel moderne.

Les crochets de validation côté serveur Subversion sont également personnalisables en fonction de vos problèmes de supervision. D’un simple logiciel de messagerie de validation à un accès sécurisé à notre démon svnpubsub, il existe un certain nombre de configurations personnalisées disponibles.

Sécurité applicative Orion

La SSR publique est une odeur

Le dynamisme du genou et le suivi de la foule ont conduit à des risques catastrophiques et à des coûts déraisonnables pour ceux qui construisent et exploitent des systèmes en ligne. Orion adopte une approche plus réfléchie et développe une technologie de contenu statique qui brouille la distinction traditionnelle en matière de réactivité entre les systèmes statiques et dynamiques. Je pense que Joe est sur quelque chose avec cette approche, et je suis impatient de voir où il peut l’emmener.
– Paul Vixie, Pionnier de l’Internet

Séparation des préoccupations et compromis techniques

En un mot, la façon dont toutes les autres plates-formes wiki fonctionnent est comme un CMS dynamique, soutenu par SQL CRU application qui permet de modifier rapidement et facilement le contenu, pour lequel les résultats doivent être reconstruits en temps réel (ou à partir d’un cache de page Web) chaque fois que quelqu’un a besoin de voir ce contenu en ligne.

Dans (noSQL) Orion, nous considérons l’édition et le rendu comme deux préoccupations distinctes qui devraient être traitées par deux piles de logiciels indépendantes ; où beaucoup plus de processus, de conception, de validation et de gestion des dépendances est investi dans l’interface d’édition. Cela nous permet de limiter le logiciel de la pile de rendu à un serveur de fichiers Apache compatible SSI Barebones avec authentification Web standard et contrôles d’accès impliqués, et de manière optimale, nous prévoyons que le contenu est vu plus souvent qu’il n’est modifié.

Par conséquent, l’expérience d’édition se produit sur une pile web indépendante impossible-à-accéder-sans-une-valid-login, est un peu moins rapide une fois les modifications téléchargées, et est beaucoup moins sale ; parce que nous validons et construisons le contenu modifié, ainsi que l’ensemble du corpus de pages dépendantes, au moment de l’édition, pas au moment du rendu. Le build se produit dans une zone d’environnement restreint et renforcée séparément. Les journaux de construction sont publiés dans la session d’édition en temps réel et enregistrés dans le contrôle des versions pour la postérité et la responsabilité des entreprises.

En réalité, le coût est de quelques secondes de plus d’exposition aux machines techniques de la construction et au processus de déploiement de fichiers statiques avant d’être en mesure de visualiser les changements validés et publiés sur le site Web de production en direct.

Et l’avantage ? Vous ne verrez jamais votre site Web en direct être piraté par des vulnérabilités zero-day ou non corrigées dans la pile logicielle du serveur Web de rendu. De plus, le site d’édition est invulnérable aux efforts de piratage anonyme, de sorte que vous êtes dans une bien meilleure position architecturale de sécurité avec nous qu’avec tout autre fournisseur de wiki sur Terre, quelles que soient les protections supplémentaires mises en œuvre dans le reste de ce document.

Un truc cool, non ?

Mais il repose de façon critique sur ce compromis qui est viable pour l’expérience du rédacteur en chef. Et sans l’application de notre brevet en attente Gestion intelligente des dépendances de contenu™ peut ne pas valoir le coût pour de nombreuses entreprises.

Gestion des listes de contrôle d’accès

Le modèle de sécurité d’Orion est géré de manière centralisée par les paramètres contenus dans @path::acl comme contraint dans lib/path.pm. Les fichiers de configuration du serveur de déconnexion sont générés dynamiquement à chaque modification créée.

Si vous comprenez le modèle de sécurité du système de fichiers POSIX, vous serez chez vous avec Orion’s mod_dav_svn modèle d’autorisation et les contrôles .htaccess du serveur web Apache HTTPd, générés automatiquement à partir de votre site web lib/acl.yml Configuration YAML.

OpenIDC Sécurité SSO

Tous les cookies de session OpenID sont marqués HttpOnly et Secure, de sorte que les tentatives de vol de session Javascript sont effectivement neutralisées par l’éditeur en ligne Orion.

Tout le stockage des informations d’identification des cookies est également chiffré AES-256 sous un hachage HMAC SHA-1.

Bcrypt pour les mots de passe Subversion

Nombre d’arrondi réglable (actuellement, la valeur par défaut est 5). Voici un entrée blog Cela explique la pertinence.

Protection des données endommagées

Toutes nos runtimes Perl ont des contrôles de tache obligatoires activés avec le drapeau -T ; un puissant, unique protection Perl contre Exploits du shell distant.

Problèmes wiki

Wiki security involves several factors:

1. Sécurité IU/API

2. Sécurité middleware/back-end

3. Protections de traversée de modèle

4. Sécurité littérale de chaîne de modèle

5. Compatibilité ACL du moteur de recherche

Nous explorons ces questions en relation avec Orion ci-dessous.

Editeur en ligne

L’éditeur en ligne prend en charge une interface utilisateur JSON en définissant simplement l’en-tête Accept de votre agent utilisateur pour préférer la application/json Type MIME, les contrôles de sécurité sont donc les mêmes pour l’interface utilisateur et l’API.

Aucune interface utilisateur/API d’administration n’est disponible en dehors de l’accès Subversion direct. Au lieu de cela, nous proposons certaines vues de données dans le moteur de recherche gratuit qui peuvent être utilisées pour créer des tableaux de bord contrôlés par accès sur le site Web hébergé.

Sinon, chaque site Web est gouverné par les fichiers de configuration dans la base du site Web. lib/ répertoire des matériaux source dans Subversion.

Les ACL Subversion régissent l’accès en lecture aux copies de travail côté serveur

Chaque ressource de copie de travail disponible via l’interface utilisateur fait l’objet d’une vérification croisée par rapport à vos ACL Subversion avant de les présenter à l’utilisateur. De cette façon, nous veillons à ce que l’accès en lecture aux ressources non autorisées soit empêché pour les ressources sous contrôle de version (aka tout).

L’accès de validation est directement contrôlé par les ACL Subversion

Rien ne peut être construit et affiché par la suite sur le réseau sans une validation Subversion autorisée correspondante. Le principal problème ici est de contrôler quelles informations sont disponibles pour les modifications validées et construites d’un auteur de page wiki.

Si vous autorisez le prétraitement de modèle dans les pages source de démarque, vous devez savoir comment les arguments de modèle rendent le contenu des autres fichiers de l’arborescence disponible en tant que variables pour la source de la page modifiée.

Souvent, si elle est configurée pour le faire, la page modifiée peut déclarer ses propres fichiers de dépendance dans les en-têtes de la page, ce qui est également quelque chose à penser lorsque vous pesez les jeux de fonctionnalités contre les contrôles de sécurité dans l’architecture d’information de votre wiki. Quelle que soit votre position, nous sécurisons votre site par défaut — incluant les dépendances de contenu et ssi inclut.

Bien que nous puissions offrir des conseils et un soutien pour répondre à vos besoins, c’est à vous de décider comment équilibrer les échelles pour les actifs gérés de votre organisation dans un wiki soutenu par Orion.

Voir la section ci-dessous sur Contrôles d’injection de dépendance/ACL pour plus de détails, et consultez cet exemple en direct de la façon dont les ACL peuvent être configurées de manière centralisée dans 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
    "*":

Les auteurs de contenu peuvent configurer les restrictions de page dans la page en-têtes:

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

Par ailleurs, les ressources protégées ne peuvent pas être copiées dans une branche par du personnel non autorisé, même sans placer de contrôles ACL supplémentaires lors de la création et de la modification de la branche. En d’autres termes, le système prendra en charge l’expérimentation des succursales sans aucun contrôle supplémentaire de votre part pour garantir que les actifs protégés restent protégés tout au long du cycle de vie naturel de chaque succursale.

Créer des listes de contrôle d’accès système ?

Le système de construction est all-seeing et all-knowing, mais nous pouvons nous assurer que vos actifs construits et protégés ne sont visibles que par les équipes que vous gérez et contrôlez dans les ACL Subversion.

Le système de compilation affiche la liste des noms de fichier qu’il a créés via l’IDE du navigateur lors d’une validation, mais cette liste est uniquement basée sur l’accès en lecture d’un utilisateur aux ressources dépendantes des actions d’ajout, de mise à jour ou de suppression de contenu de l’utilisateur dans la validation.

Contrôles de traversée de modèle

Voir sanitize_relative_path:

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

Ce code applique les règles qui suivent ci-dessous dans cette section.

inclure et étendre les balises

Tous les fichiers cible se trouvent dans un sous-dossier de /templates/ et doit être référencé en tant que chemins absolus ancrés dans ce dossier.

balise ssi

Tous les fichiers cible se trouvent dans un sous-dossier de /content/ et doit être référencé en tant que chemins absolus ancrés dans ce dossier.

Si le chemin cible n’est pas configuré dans @path::patterns avec un paramètre de correspondance qui permet d’archiver ou de catégoriser le chemin cible en question, ou le dernier auteur modifié du fichier source n’est tout simplement pas autorisé à afficher le chemin cible, le ssi l’opération échouera.

C’est parce que ssi Le support est un prérequis pour ces jeux de fonctionnalités, afin de préserver la cible de votre site permalinks.

Sécurité des filtres impliquant des expressions régulières transmises en tant que littéraux de type chaîne

Dotiac::DTL urlencode en interne tous les littéraux de type chaîne avant de les exposer à eval pour des raisons de sécurité. Il les laisse ensuite codés lorsqu’ils sont transmis en tant qu’arguments de filtre, ce qui est frustrant lorsque vous travaillez avec des littéraux de chaîne PCRE.

Dans cette situation, notre fourche de Dotiac::DTL urldécode la chaîne et effectue un contrôle d’intégrité dans un Safe::reval Sandbox avant de les exposer à perlLe moteur d’expression régulière. L’avantage est que les littéraux de type chaîne que vous saisissez dans un argument de filtre pris en charge seront exposés mot pour mot à mot à perl — vous n’avez pas besoin d’échapper deux fois vos barres obliques inverses.

Contrôles d’injection de dépendance/ACL

Contrôlé par lib/path.pm importations.

lib./{chemin,vue}.pm Liste de contrôle d’accès Subversion

Il est sage de contrôler l’accès en écriture à ces ressources, en les limitant aux personnes à la fois compétentes dans la base de code et autorisées à mettre en œuvre des contrôles de sécurité pour l’ensemble des ressources sous contrôle de version (aka tout).

C’est aussi une bonne idée d’inclure le @svnadmin groupe parmi ceux qui ont un accès en lecture-écriture, mais ce n’est pas strictement nécessaire même si vous avez besoin de nous pour réinitialiser manuellement vos ACL Subversion.

Règles générées dynamiquement via @chemin : :acl

Le système de paramétrage prend note de votre lib/path.pm les importations de seed_file_deps() et seed_file_acl(), ou des deux, et le report de ce choix dans son traitement interne des modifications de validation Subversion qui donnent lieu à une construction incrémentielle.

Suivi de la migration du contenu contrôlé

Lorsque vous exposez l’historique complet des contrôles de version à vos utilisateurs, veillez à conserver les contrôles d’autorisation sur l’emplacement d’origine du matériel contrôlé.

Sinon, le matériel pourrait être inversement exposé à un chercheur historique sans les autorisations requises.

La logique de suivi de déplacement/suppression d’Orion CMS gère cela de manière transparente.

Contrôles personnalisés sur l’utilisation de seed_file_deps() et de seed_file_acl() dans lib/path.pm

Au-delà de l’importation de ces symboles lib/path.pm, vous pouvez également choisir comment et à quels fichiers vous souhaitez les appliquer lors de l’exécution d’un bloc de code walk_content_tree (). Après tout, ce n’est pas seulement un fichier de configuration, mais une base de code, avec toutes les fonctionnalités complètes de Turing. Perl Nous avons appris à connaître et à apprécier !

Les fichiers .htaccess de site Web créés et les fichiers d’autorisation Subversion sont synchronisés avec @path::acl instantanément lors de l’engagement

Protection automatique de l’ACL pour les constructions de branches éphémères. Aucune configuration supplémentaire requise.

Contrôles intégrés du moteur de recherche PCRE

Same situation as the general-purpose UI: il effectue des vérifications croisées sur le serveur Subversion à partir de l’interface utilisateur.

Sur le site en direct, le moteur de recherche fera exactement la même chose lorsque vous activerez les recherches Markdown (arborescence source). Sinon, il exécutera des sous-demandes httpd sur votre site live pour vérifier si l’utilisateur est autorisé à accéder à ce fichier live (en supposant que vous ayez protégé votre moteur de recherche par mot de passe afin qu’il dispose de données utilisateur pour fonctionner).

Stratégies de sécurité du contenu

• Restrictions d’analyse

Google, X et/ou LinkedIn.

• Restrictions de données

Les données doivent être fournies à partir de nos serveurs.

• Restrictions de contenu

Le contenu doit être livré à partir de nos serveurs.

• Restrictions de code

Javascript Code doit être livré à partir de nos serveurs.

• Restrictions de style

CSS doit être livré à partir de nos serveurs.

• Restrictions de plug-in

Actuellement PDF uniquement.

Partage de ressources d’origine croisée

• Tous les utilisateurs disposant d’un compte peuvent utiliser des interfaces utilisateur/API d’ailleurs à l’aide de leurs informations d’identification de connexion.

• Les entreprises peuvent traiter Orion comme un CMS sans tête s’ils souhaitent créer leur propre interface utilisateur à partir de JSON Subversion Porcelaine ou Recherche JSON API.

Dépendances tierces

Dépendances remarquablement brèves et éprouvées, dont les principales composantes sont Technologie Orion page.

Nomenclature logicielle complète (SBOM) disponible sur demande

Nous contacter pour plus de détails.