Orion Security

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

Paraphasage populaire de serrurier américain Alfred Charles Hobbs en 1851, qui a facilement choisi les serrures Crystal Palace lors d’une exposition londonienne cette année-là. Nous sommes entièrement d’accord, c’est pourquoi nos modèles de base pour notre moteur d’automatisation Oracle Cloud Infrastructure (OCI) sont disponible sur GitHub.

Sécurité de l’infrastructure Orion

flowchart TB classDef borderless stroke-width:0px classDef darkBlue fill:#00008B, color:#fff classDef brightBlue fill:#6082B6, color:#fff classDef gray fill:#62524F, color:#fff classDef gray2 fill:#4F625B, color:#fff subgraph vcs[ ] A1[[Fort Lauderdale, FL]] B1[Air-Gapped Version Control Server] end class vcs,A1 gray subgraph vpn-us-east[ ] A2[[Reston, VA]] B2[OCI Edge Servers] end class vpn-us-east,A2 darkBlue subgraph vpn-us-west[ ] A3[[Phoenix, AZ]] B3[OCI Edge Servers] end class vpn-us-west,A3 darkBlue subgraph vpn-de-central[ ] A4[[Frankfurt, Germany]] B4[OCI Edge Servers] end class vpn-de-central,A4 darkBlue subgraph vpn-bz-west[ ] A5[[São Paolo, Brazil]] B5[OCI Edge Servers] end class vpn-bz-west,A5 darkBlue subgraph vpn-au-west[ ] A6[[Sydney, Australia]] B6[OCI Edge Servers] end class vpn-au-west,A6 darkBlue subgraph vpn-ap-west[ ] A7[[Hyderabad, India]] B7[OCI Edge Servers] end class vpn-ap-west,A7 darkBlue subgraph vpn-ap-east[ ] A8[[Seoul, South Korea]] B8[OCI Edge Servers] end class vpn-ap-east,A8 darkBlue class A1,A2,A3,A4,A5,A6,A7,A8 borderless vcs==vpn==>A2==ssh/vpn==>B2 vcs==vpn==>A3==ssh/vpn==>B3 vcs==vpn==>A4==ssh/vpn==>B4 vcs==vpn==>A5==ssh/vpn==>B5 vcs==vpn==>A6==ssh/vpn==>B6 vcs==vpn==>A7==ssh/vpn==>B7 vcs==vpn==>A8==ssh/vpn==>B8

 

Compatible FIPS 140-2 avec triple chiffrement MFA pour les services retransmis par port inversé (HTTPS/SSH/IPsec). Ceinture, bretelles et étriers !


 

Passwordless RBAC modèle, poivré avec orthèse otp-sha1.

Aucun mot de passe fixe stocké sur les serveurs. Cette automatisation sans tête limite de l’utilisation de sudo / RBAC, pour une bonne raison. Cependant, nous avons outils.

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

Nous déployons des builds de zone “sans partage”, avec une disponibilité réseau nulle par défaut. Cela signifie que les seules choses auxquelles un client peut accéder ou modifier sont ses propres actifs, pas ceux de tout autre client, ou tout autre chemin système sur la zone elle-même (en plus de /tmp.

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

Chiffrement de bout en bout

Aspects de confiance zéro

Le principe de base de architecture à confiance zéro est d’éviter de concevoir la sécurité de votre réseau autour de la physiologie de la palourde : dure à l’extérieur, mais douce 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 de point de présence (POP) est seulement exposé à l’interface de périphérique de loopback de la machine bare-metal. lo0.

Cet infra est entièrement automatisé une fois qu’une région est mise en ligne, mais c’est tout ce que nous pouvons partager publiquement au sujet de l’architecture (équilibrer la transparence Hobbsienne avec le mantra militaire “navires couleurs à lèvres lâches” est plus art que science). Soyez assuré — au-delà de la rupture de l’antispoofing lo0.

Même si le compte de contrôle OCI maître est compromis, la confidentialité et l’ intégrité de toutes les ressources client restent inviolables. Tout ce qu’un chapeau noir peut faire est de faire un gâchis avec le site Web du client disponibilité. 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 en 48 à 72 heures après la fin de l’accès OCI de la mauvaise pomme.


Journalisation, surveillance et audit

Nous encourageons les clients Enterprise à créer un compte Splunk, et nous fournirons des blogs en temps quasi réel à votre compte à partir de chaque POP mondial dont vous avez besoin. Les journaux d’erreurs de votre script 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 régional ou de haute disponibilité si une panne de serveur dure plus de 30 secondes.

L’audit d’ACL peut être effectué en créant 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 pour le www/.acl.

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


Sécurité de l’application Orion

digraph { "@path::acl" -> "authz-svn.conf" [label="svn"]; "@path::acl" -> "/**/.htaccess" [label="httpd"]; };

 

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.

OpenIDC Sécurité SSO

Les cookies de session 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.

Chiffrement pour les mots de passe Subversion

Nombre ajustable de tours (actuellement, la valeur par défaut est 5).

Protection des données contaminées

Toutes nos exécutions Perl ont des contrôles de tache obligatoires activés avec l’indicateur -T ; une protection Perl puissante et unique contre les exploits de shell à distance.

Problèmes Wiki

La sécurité Wiki implique plusieurs facteurs :

  1. Sécurité de l’interface utilisateur/API

  2. Sécurité du middleware/back-end

  3. Protections de traversée de modèle

  4. Compatibilité ACL du moteur de recherche

Nous explorons ces questions comme elles se rapportent à 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 qu’il préfère application/json.

Il n’existe aucune interface utilisateur/API d’administration en dehors de l’accès direct à 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 est vérifiée par rapport à vos listes de contrôle d’accès Subversion avant de les présenter à l’utilisateur. De cette façon, nous veillons à ce que l’accès en lecture aux retours non autorisés soit empêché pour les ressources sous contrôle de version (c’est-à-dire tout).

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

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

Si vous autorisez le prétraitement des modèles 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 accessible en tant que variables à 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 quelque chose à penser lorsque vous pesez des ensembles de fonctionnalités par rapport aux contrôles de sécurité dans l’architecture d’information de votre wiki.

Bien que nous puissions offrir des conseils et du soutien pour répondre à vos besoins, c’est vraiment à vous de décider comment équilibrer les échelles pour le wiki d’entreprise de votre organisation.

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 manière 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:
    "@marketing": rw
    "@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:
    "*":

Les auteurs de contenu peuvent configurer des 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

Notez que les ressources protégées ne peuvent pas être copiées dans une branche par un personnel non autorisé, même sans placer de contrôles ACL supplémentaires sur la création et 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 s’assurer 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 omniscient et omniscient, 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 listes de contrôle d’accès Subversion.

Le système de compilation affichera la liste des noms de fichiers 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épendant 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 dans cette section.

inclure et étendre les balises

Tous les fichiers cible se trouvent dans un sous-dossier du /modèles/.

balise ssi

Tous les fichiers cible se trouvent dans un sous-dossier du /contenu/.

Si le chemin cible n’est pas configuré dans @path : :modèles avec un paramètre de correspondance qui permet au chemin cible en question d’être archivé ou catégorisé, le ssi.

C’est parce que ssi.

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

Contrôlé par lib/path.pm.

ACL de Subversion lib/{path,view}.pm

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

C’est aussi une bonne idée d’inclure le @svnadmin.

Règles générées dynamiquement via @

Le système de construction prend note de votre lib/path.pm.

Commandes personnalisées sur l’utilisation de seed_file_deps() et seed_file_acl() dans lib/path.pm

Au-delà de l’importation de ces symboles à lib/path.pm, vous avez également le choix entre la méthode et les fichiers auxquels 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. Perle.

Site Web construit et ACL Subversion synchronisées avec @

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

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

Même situation que l’interface utilisateur à usage général : elle effectue un contrôle croisé 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 activez les recherches de démarque (arborescence source). Sinon, il exécutera des sous-requêtes httpd sur votre site actif pour vérifier si l’utilisateur est autorisé à accéder à ce fichier actif (en supposant que vous avez protégé par mot de passe votre moteur de recherche afin qu’il dispose de données utilisateur pour travailler avec).

Stratégies de sécurité du contenu

Google et/ou LinkedIn.

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

Le contenu doit être fourni à partir de nos serveurs.

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

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

Actuellement en PDF.

Partage de ressources multiorigines

dépendances tierces

Des dépendances remarquablement brèves et éprouvées, dont les principales composantes sont couvertes par le Technologie Orion.

Nomenclature logicielle (SBOM) disponible sur demande

Nous contacter.


Index