Orion-Sicherheit

“Sicherheit durch Dunkelheit ist überhaupt nicht viel Sicherheit.”

Beliebte Paraphierung des amerikanischen Schlossers Alfred Charles Hobbs 1851, der während einer Londoner Ausstellung in diesem Jahr leicht die Crystal Palace Schlösser auswählte. Wir sind uns voll und ganz einig, weshalb unsere Blueprints für unsere Oracle Cloud Infrastructure-(OCI-)Automatisierungs-Engine verfügbar auf GitHub.

Sicherheit der Orion-Infrastruktur

FIPS 140-3-konform mit MFA-Dreifachverschlüsselung für Reverse-Port-Weiterleitungsservices (HTTPS/SSH/IPsec). Gürtel, Hosenträger und Steigbügel!

RBAC Modell, gepfeffert mit Atrus OTP/TOTP-Herausforderungen

Der gesamte Anmeldezugriff für den Infrastrukturaccount erfordert die Bereitstellung von Zugangsdaten für die Multifaktor-Authentifizierung, einschließlich OCI-Accounts. Es gibt keine Hintertüren zu dieser Richtlinie.

Für den SSH-Zugriff aller Mitarbeiter auf Unternehmensrechner ist eine YubiKey PKI-Integration mit privaten ECDSA-SHA-2-NISTP-256-Autorisierungsschlüsseln erforderlich, die in PKCS11-Slots auf dem Yubikey gespeichert sind, oder eine direkte Smartcard-Integration mit ED25519-sk Pkeys.

Keine festen Passwörter auf Festplatten gespeichert. Diese limits kopflose Automatisierung von sudo / RBAC Nutzung, aus gutem Grund. Allerdings haben wir Werkzeug die Mühe zu beseitigen, auf Aufforderungen verschiedener Art zu reagieren.

Sandboxed-Ausführung für Builds und CGI-Skripte

Wir stellen “Shared-Nichts” Zonen-Builds, Standard ist null Netzwerkverfügbarkeit. Dies bedeutet, dass ein Kunden-Build nur auf seine eigenen Assets zugreifen oder diese ändern kann, nicht auf die anderen Kunden oder auf andere Systempfade in der Zone selbst (neben /tmp. Darüber hinaus haben nur Geschäfts- und Unternehmenskunden während ihrer Builds Internetzugriff, da sie ihre eigenen eindeutigen Solaris-Zonen verwenden, die genau auf ihre Build-Anforderungen zugeschnitten werden können.

Ditto für CGI-Skripte, die vollständig im Hinblick auf den Schreibzugriff auf andere als /tmp.

Ende-Ende-Verschlüsselung

• OpenSSL v4+ TLS 1.3 (+FS) AES(256) SHA(256) für HTTPS-FIPS 140-3-Verbindungen

• OpenSSH v10+ ED25519 FIPS 140-3 mit Post-Quantum KexAlgorithm-/NIST-konformen Schlüsseln für hostübergreifende Verbindungen lo Reverse-Port-Weiterleitung

• IPsec/IKEv2/PFS AES(256) FIPS 140-2 für regionsübergreifendes VPN

• AES(256) für ZFS-Verschlüsselung

Zero Trust-Aspekte

Die Grundvoraussetzung von Zero Trust-Architektur Es ist zu vermeiden, Ihre Netzwerksicherheit um die Physiologie der Muschel zu gestalten: hart auf der Außenseite, aber weich und locker, wenn Sie in sind. Das tun wir nicht; jeder bedeutende privilegierte Netzwerkport innerhalb der verschiedenen Point of Presence-(POP-)LANs ist nur der Loopback-Geräteschnittstelle des Bare-Metal-Rechners ausgesetzt lo0, und ist nur im Kontext einer (umgekehrten) übermittelten SSH-Verbindung zu dieser sinnvoll.

Wir verwenden TCP-Proxys, keine HTTP-Proxys und keine MSA-Backends. Der einzige Host, der Ihren unverschlüsselten TLS-Webverkehr sieht, ist der Host, der ihn entschlüsselt. Dieselben Regeln gelten für Subversion-Traffic — Nur direkter, End-to-End-TLS-verschlüsselter Datenverkehr zum Service-Endpunkt sieht Ihre unverschlüsselten Daten auf der Leitung.

Viel Glück mit den MSA-Ebenen und Ebenen der privaten Datenexposition mit anderen Anbietern. Der Feind von “Nichtfunktionales Engineering” Komplexität ist. Es ist viel einfacher, aussagekräftige Sicherheitsversprechen zu geben, wenn Ihr Produkt ein föderierter Monolith anstelle eines massiven MSA-Minenfeldes ist, was ein weiteres konträres Unterscheidungsmerkmal zwischen Orion und seinem Wettbewerbsgebiet ist.

Diese Infrastruktur ist vollständig automatisiert, sobald eine Region online gestellt wird, aber das ist alles, was wir öffentlich über die Architektur teilen können (Ausgleich der hobbsischen Transparenz mit dem militärischen Mantra) “Lose Lippen spülen Schiffe” mehr Kunst als Wissenschaft). Sicher sein — über das Brechen des Antispoofings hinaus lo0 Schutz innerhalb des BSD-Paketfilters (Solaris 11) selbst gibt es keine sinnvollen Möglichkeiten, Zugriff auf diese Services zu erhalten, selbst für Kundenkonten.

Selbst wenn der Master-OCI-Kontrollaccount kompromittiert ist, bleibt die Vertraulichkeit und Integrität aller Kundenassets unverletzlich. Alles, was ein Black-Hat tun kann, ist ein Chaos mit der Kundenwebsite Verfügbarkeit zu machen. Insbesondere können sie nicht auf die Subversion-Servicedatensätze zugreifen. Wir können die gesamte OCI-Infrastruktur in 48-72 Stunden von Grund auf neu rekonstruieren, nachdem der OCI-Zugriff des schlechten Apfels beendet wurde.

Logging, Überwachung und Auditing

Wir empfehlen Enterprise-Kunden, ein Splunk-Konto zu erstellen, und wir werden Ihrem Konto nahezu Echtzeit-Weblogs von jedem globalen POP aus bereitstellen, den Sie benötigen. Fehlerprotokolle für das serverseitige CGI-Skripting werden auch Splunk zur Verfügung gestellt.

Wir überwachen die Serviceverfügbarkeit von allen unseren OCI-POPs weltweit und lösen HA (Availability-Domain) oder regionale Failover-Ereignisse aus, wenn ein Serverausfall länger als 30 Sekunden dauert.

ACL Auditing kann durchgeführt werden, indem Sie einfach den Subversion HEAD einer Website mit dem Apache Licensed erstellen Orion SSG Skript und Prüfung des resultierenden Builds www/.acl Datei in Ihrem Kassenausgangsverzeichnis, jederzeit wünschen. Normalerweise dauert der Build-Prozess auf moderner Hardware weniger als 10-15 Sekunden.

Subversion Server-seitige Commit-Hooks sind auch an Ihre Aufsichtsprobleme anpassbar. Von einem einfachen Commit-Mailer bis hin zum sicheren Zugriff auf unseren svnpubsub-Daemon gibt es eine beliebige Anzahl von benutzerdefinierten Konfigurationen.

Orion-Anwendungssicherheit

Öffentliche SSR ist ein Geruch

Knie-Ruck-Dynamik und Crowd-Following haben zu katastrophalen Risiken und unvernünftigen Kosten für diejenigen geführt, die Online-Systeme bauen und betreiben. Orion verfolgt einen mehr überlegten Ansatz und entwickelt statische Content-Technologie, die den traditionellen Unterschied in der Reaktionsfähigkeit zwischen statischen und dynamischen Systemen verwischt. Ich denke, Joe ist auf etwas mit diesem Ansatz, und ich bin gespannt, wo er es nehmen kann.
– Paul Vixie, Internet-Pionier

Trennung von Bedenken und technischen Kompromissen

Kurz gesagt, die Art und Weise, wie jede andere Wiki-Plattform funktioniert, ist als dynamisches CMS, SQL-gestützt. CRUD App, die es schnell und einfach macht, Inhalte zu ändern, für die die Ergebnisse in Echtzeit (oder aus einem Webseiten-Cache) jedes Mal neu erstellt werden müssen, wenn jemand diesen Inhalt online ansehen muss.

In (noSQL) Orion nehmen wir das Bearbeiten und Rendering als zwei separate Bedenken an, die von zwei unabhängigen Software-Stacks behandelt werden sollten; wobei viel mehr Prozess-, Design-, Validierungs- und Abhängigkeitsmanagement in die Bearbeitungsoberfläche investiert wird. Dies ist so, dass wir die Software auf dem Rendering-Stack auf einen Barebones SSI-fähigen Apache-Dateiserver mit moorstandardmäßiger Webauthentifizierung und Zugriffskontrolle beschränken können, und optimistisch erwarten wir, dass der Inhalt öfter in einer Größenordnung angezeigt wird, als er bearbeitet wird.

Folglich erfolgt die Bearbeitung auf einem unzugänglich-ohne-valid-login unabhängigen Web-Stack, ist etwas weniger schnell, sobald die Änderungen hochgeladen werden, und ist viel weniger schmutzig; weil wir den geänderten Inhalt zusammen mit dem gesamten Korpus abhängiger Seiten validieren und erstellen, zur Bearbeitungszeit, nicht zur Renderzeit. Der Build erfolgt in einer separat gehärteten, sandboxed Solaris Zone. Die Build-Logs werden in Echtzeit in der Bearbeitungssession veröffentlicht und in der Versionskontrolle gespeichert, um die Nachwelt und die geschäftliche Verantwortung zu gewährleisten.

In Wirklichkeit sind die Kosten ein paar Sekunden mehr der Exposition gegenüber den technischen Maschinen des Builds und dem statischen Dateibereitstellungsprozess, bevor sie in der Lage sind, festgeschriebene, veröffentlichte Änderungen auf der Live-Produktionswebsite anzuzeigen.

Und der Nutzen? Sie werden nie sehen, dass Ihre Live-Website erneut gehackt wird durch Zero-Day- oder ungepatchte Schwachstellen im Software-Stack des Rendering-Webservers. Darüber hinaus ist die Bearbeitungsseite ungefährlich für anonyme Hacking-Bemühungen, so dass Sie bei uns in einer viel besseren sicherheitsarchitektonischen Position sind als bei jedem anderen Wiki-Anbieter auf der Erde, unabhängig von den zusätzlichen Schutzmaßnahmen, die im Rest dieses Dokuments implementiert sind.

Toller Trick, nicht wahr?

Aber es hängt entscheidend davon ab, dass Tradeoff für die Editor-Erfahrung tragfähig ist. Und ohne Anmeldung unserer Patentanmeldung Smart Content-Abhängigkeitsmanagement™ Die Kosten für viele Unternehmen sind vielleicht nicht wert.

ACL-Verwaltung

Das Sicherheitsmodell von Orion wird zentral von den Einstellungen verwaltet, die in @path::acl als verstopft in lib/path.pm. Offshoot-Serverkonfigurationsdateien werden bei jeder erstellten Änderung dynamisch generiert.

Wenn Sie das Sicherheitsmodell des POSIX-Dateisystems verstehen, sind Sie mit Orion zu Hause. mod_dav_svn Autorisierungsmodell und die .htaccess-Steuerelemente des Apache HTTPd-Webservers, die automatisch von der lib/acl.yml YAML-Konfiguration.

OpenIDC SSO-Sicherheit

Alle OpenID-Sessioncookies sind HttpOnly und “Sicher” gekennzeichnet, sodass Javascript-Session-Stealing-Versuche vom Orion Online Editor effektiv neutralisiert werden.

Alle Cookie-Zugangsdaten werden zusätzlich AES-256 verschlüsselt unter einem HMAC SHA-1 Hash.

Bcrypt für Subversion-Kennwörter

Anpassbare Anzahl von Runden (derzeit standardmäßig 5). Hier ist ein Blog-Eintrag Das erklärt die Relevanz.

Beschädigter Datenschutz

Alle unsere Perl-Laufzeiten haben obligatorische Taint-Prüfungen mit der -T-Flagge aktiviert; ein leistungsstarker, einzigartiger Perl-Schutz gegen Remote-Shell-Exploits.

Wiki-Probleme

Wiki security involves several factors:

1. UI-/API-Sicherheit

2. Middleware-/Backend-Sicherheit

3. Schutz vor Vorlagendurchlauf

4. Vorlagenzeichenfolge - Literale Sicherheit

5. ACL-Kompatibilität für Suchmaschine

Wir befassen uns mit diesen Themen, wie sie sich unten auf Orion beziehen.

Online-Editor

Der Online-Editor unterstützt eine JSON-UI, indem Sie einfach den Accept-Header Ihres Benutzer-Agent so einstellen, dass er die application/json MIME-Typ, sodass die Sicherheitskontrollen sowohl für die UI als auch für die API identisch sind.

Außerhalb des direkten Subversion-Zugriffs ist keine administrative UI/API vorhanden. Stattdessen bieten wir bestimmte Daten views in der kostenlosen Suchmaschine an, die verwendet werden können, um zugriffsgesteuerte Dashboards innerhalb der gehosteten Website zu erstellen.

Andernfalls wird jede Website von den Konfigurationsdateien in der Basis der Website gesteuert lib/ Verzeichnis der Quellmaterialien in Subversion.

Subversion-ACLs steuern den serverseitigen Lesezugriff auf Arbeitskopien

Jede über die Benutzeroberfläche verfügbare Arbeitskopierressource wird mit Ihren Subversion-ACLs verglichen, bevor sie dem Benutzer präsentiert wird. Auf diese Weise stellen wir sicher, dass der Lesezugriff auf nicht autorisierte Ressourcen für die Assets unter Versionskontrolle (auch alles genannt) verhindert wird.

Commit-Zugriff wird direkt mit Subversion-ACLs gesteuert

Nichts kann ohne einen entsprechenden autorisierten Subversion Commit über das Netzwerk erstellt und anschließend angezeigt werden. Das Hauptproblem hier ist, zu kontrollieren, welche Informationen für die engagierten und erstellten Bearbeitungen eines Wiki-Seitenautors verfügbar sind.

Wenn Sie die Vorverarbeitung von Vorlagen auf den Markdown-Quellseiten zulassen, müssen Sie wissen, wie Vorlagenargumente den Inhalt anderer Dateien im Baum als Variablen für die Quelle der bearbeiteten Seite verfügbar machen.

Oft kann die bearbeitete Seite, wenn sie dazu konfiguriert ist, ihre eigenen Abhängigkeitsdateien in den Kopfzeilen der Seite deklarieren, was auch zu beachten ist, wenn Sie Feature-Sets gegen Sicherheitssteuerelemente in der Informationsarchitektur Ihres Wikis abwägen. Unabhängig von Ihrer Haltung sichern wir Ihre Website standardmäßig — einschließlich Inhaltsabhängigkeiten und ssi beinhaltet.

Wir können zwar Anleitung und Unterstützung anbieten, um Ihre Bedürfnisse zu erfüllen, aber es liegt wirklich an Ihnen, zu entscheiden, wie Sie die Waagen für die verwalteten Assets Ihrer Organisation in einem von Orion unterstützten Wiki ausgleichen.

Siehe folgenden Abschnitt auf Abhängigkeits-/ACL-Injection-Steuerelemente für weitere Details und Checkout dieses Live-Beispiels, wie einfach ACLs zentral konfiguriert werden können 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
    "*":

Inhaltsautoren können Seitenbeschränkungen in den Seiten konfigurieren Kopfzeilen:

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

Geschützte Ressourcen können von nicht autorisiertem Personal nicht in eine Verzweigung kopiert werden, auch wenn keine zusätzlichen ACL-Steuerelemente bei der Erstellung und Änderung von Verzweigungen vorhanden sind. Mit anderen Worten, das System unterstützt Zweigsexperimente ohne zusätzliche Kontrollen Ihrerseits, um sicherzustellen, dass geschützte Assets während des gesamten natürlichen Lebenszyklus jeder Filiale geschützt bleiben.

System-ACLs erstellen?

Das Build-System ist allsehend und allwissend, aber wir können sicherstellen, dass Ihre gebauten, geschützten Assets nur für die Teams sichtbar sind, die Sie in den Subversion-ACLs verwalten und kontrollieren.

Das Build-System zeigt die Liste der Dateinamen an, die es bei einem Commit über die Browser-IDE erstellt hat. Diese Liste basiert jedoch nur auf dem Lesezugriff eines Benutzers auf die Ressourcen, je nachdem, welche Inhaltsaktionen der Benutzer beim Commit hinzufügen, aktualisieren oder löschen.

Durchlaufkontrollen für Vorlage

Siehe sanitize_relative_path:

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

Dieser Code erzwingt die folgenden Regeln in diesem Abschnitt.

Tags einschließen und erweitern

Alle Zieldateien befinden sich in einem Unterordner der /templates/ Ordner und muss als absolute Pfade referenziert werden, die in diesem Ordner verwurzelt sind.

SSI-Tag

Alle Zieldateien befinden sich in einem Unterordner der /content/ Ordner und muss als absolute Pfade referenziert werden, die in diesem Ordner verwurzelt sind.

Wenn der Zielpfad nicht konfiguriert ist in @path::patterns mit einer übereinstimmenden Einstellung, mit der der betreffende Zielpfad entweder archiviert oder kategorisiert werden kann, oder der zuletzt geänderte Autor der Quelldatei einfach nicht autorisiert ist, den Zielpfad anzuzeigen, ssi Vorgang nicht erfolgreich.

Das liegt daran, ssi Unterstützung ist eine Voraussetzung für diese Featuresets, um das Ziel Ihrer Site permalinks beizubehalten.

Filtersicherheit für reguläre Ausdrücke, die als Zeichenfolgenliterale übergeben werden

Dotiac::DTL intern urlenkodiert alle Zeichenfolgenliterale, bevor sie eval aus Sicherheitsgründen. Es lässt sie dann codiert, wenn sie als Filterargumente übergeben werden, was bei der Arbeit mit PCRE-Zeichenfolgenliteralen frustrierend ist.

In dieser Situation, unsere Gabel von Dotiac::DTL urldecodiert die Zeichenfolge und führt eine Integritätsprüfung durch Safe::reval Sandbox, bevor sie ausgesetzt werden perlRegex-Engine. Der Vorteil ist, dass die Zeichenfolgenliterale, die Sie in ein unterstütztes Filterargument eingeben, wörtlich angegeben werden. perl — Sie brauchen Ihre umgekehrten Schrägstriche nicht zu verdoppeln!

Abhängigkeits-/ACL-Injection-Steuerelemente

Kontrolliert von lib/path.pm Importe.

Bibliothek/{Pfad, Anzeigen}.pm Subversion-ACLs

Es ist ratsam, den Schreibzugriff auf diese Ressourcen zu kontrollieren, indem sie auf Personen beschränkt werden, die sowohl in der Codebasis als auch autorisiert sind, Sicherheitskontrollen für den gesamten Satz von Assets unter Versionskontrolle (auch bekannt als *alles *) zu implementieren.

Es ist auch eine gute Idee, die @svnadmin Gruppe unter denen mit Lese-Schreibzugriff, aber es ist nicht unbedingt notwendig, auch wenn Sie uns benötigen, um Ihre Subversion-ACLs manuell zurückzusetzen.

Dynamisch generierte Regeln über @Pfad::acl

Das Build-System nimmt Ihre lib/path.pm Importe von seed_file_deps() und seed_file_acl() oder beides und übertragen diese Auswahl bei der internen Verarbeitung von Subversion Commit-Änderungen, die zu einem inkrementellen Build führen.

Tracking der kontrollierten Inhaltsmigration

Wenn Sie den Benutzern die vollständige Versionskontrollhistorie zur Verfügung stellen, müssen Sie darauf achten, dass die Autorisierungskontrollen am ursprünglichen Standort des kontrollierten Materials beibehalten werden.

Andernfalls könnte das Material versehentlich einem historischen Forscher ohne die erforderlichen Autorisierungen ausgesetzt werden.

Die Verfolgungslogik des Orion CMS zum Verschieben/Löschen übernimmt diese nahtlos.

Benutzerdefinierte Steuerelemente für die Verwendung von seed_file_deps() und seed_file_acl() in lib/path.pm

Neben dem Import dieser Symbole auf lib/path.pm, gibt es auch eine Wahl, wie und auf welche Dateien Sie sie anwenden möchten, während einer walk_content_tree ()-Codeblockausführung. Schließlich ist es nicht nur eine Konfigurationsdatei, sondern eine Codebasis, mit allen Turing-Funktionen. Perl Wir haben uns kennengelernt und schätzen gelernt!

Built Website .htaccess-Dateien und Subversion-Autorisierungsdateien werden synchronisiert mit @path::acl sofort nach Commit

Automatischer ACL-Schutz für ephemere Zweig-Builds. Keine zusätzliche Konfiguration erforderlich.

Integrierte Steuerelemente für PCRE-Suchmaschine

Same situation as the general-purpose UI: Es prüft über die Benutzeroberfläche gegen den Subversion-Server.

Auf der Live-Website wird die Suchmaschine dasselbe tun, wenn Sie Markdown-Suchen (Quellbaum) aktivieren. Andernfalls führt es httpd-Unteranfragen auf Ihrer Live-Site aus, um zu testen, ob der Benutzer autorisiert ist, auf diese Live-Datei zuzugreifen (vorausgesetzt, Sie haben Ihre Suchmaschine passwortgeschützt, damit sie mit Benutzerdaten arbeiten kann).

Inhaltssicherheits-Policys

• Analyseeinschränkungen

Google, X und/oder LinkedIn.

• Dateneinschränkungen

Daten müssen von unseren Servern geliefert werden.

• Inhaltseinschränkungen

Die Inhalte müssen von unseren Servern geliefert werden.

• Codeeinschränkungen

Javascript Code muss von unseren Servern ausgeliefert werden.

• Stileinschränkungen

CSS muss von unseren Servern geliefert werden.

• Plugin-Einschränkungen

Derzeit nur PDF.

Quellübergreifende Ressourcenfreigabe

• Alle Benutzer mit einem Account können UI/APIs von anderswo mit ihren Anmeldedaten nutzen.

• Geschäfts- und Unternehmenskunden können Orion als Headless CMS wenn sie ihre eigene Benutzeroberfläche aus der JSON Subversion Porzellan oder JSON-Suche APIs.

Abhängigkeiten von Drittanbietern

Bemerkenswert kurze und bewährte Abhängigkeiten, deren Hauptbestandteile auf der Orion-Technologie Seite.

Full Software Bill of Materials (SBOM) auf Anfrage erhältlich

Kontakt für weitere Details.